Архив метки: процессы

Подождите, сейчас разрушу вашу компанию, никуда не уходите

prostiteКнига Карен Фелан, «Простите, я разрушил вашу компанию». Кто такая Карен? Консультант, основатель консалтинговой фирмы Operating Principals.

Основная идея книги в том, чтобы не пользоваться бездумно услугами внешних консультантов. Ибо они, по мнению Карен, запросто могут терминировать вашу драгоценную компанию. Ну естественно, это не односторонняя, радикальная позиция. Автор приводит ряд областей (реинжиниринг, стратегическое планирование, внедрение системы показателей и т.п.), в которых консалтеры, особенно из крупных консалтерских фирм, применяют стандартные подходы, в конце концов отправляющие фирму под откос.
Например, она упоминает Enron, в которой по совету McKinsey ввели дифференциацию сотрудников на классы А, В и С. Считается, что внедрение этой «звездной системы» косвенно привело компанию к краху.

Итак, книжка неоднозначная, но в целом правильная и полезная. Must read.
Некоторые мысли из книги.

1. Планирование стратегии? Только в пределах разумного.

Вспомни черного лебедя Талеба. Но есть хорошие примеры — Улисс Грант, Дуайт Эйзентхауэр — «при подготовке к сражению…планы бесполезны, а вот планирование — обязательно». Таким образом, разработка стратегии и планов компании — должно стать постоянным динамическим процессом изучения текущей реальности, и корректировки. Планирование — обязательно, п.ч. без этого не узнаешь деталей, которые понадобятся для следующего шага после начала сражения.

2. Показатели — это средства, а не цели. 

kpi

Я знал это, чувствовал, но не знал как выразить:)  Моя процессная душа всегда была за метрики, но подвох чувствовался всегда!
Цели есть у всех. Наиболее продвинутые пытаются создать систему метрик, описывающих критерии достижения этой цели. Например — хочу похудеть. Тут же метрика всплывает — 12 кг за 3 мес. Что тут плохого? А то, что цель на самом деле — похудеть, не ухудшив здоровья. Чувствуете разницу? Чтобы правильно описать настоящую цель, придется выпиливать огромную систему показателей. И на кого тогда мы похожи? На водил, упертых в свои приборные панели. Но чтобы не разбиться, нужно на дорогу смотреть, и лишь иногда на панель.

Про дорогу и панель — может немного утрированно, но жизнь показывает, что компании, кровью строящие свой бизнес на метриках — плохо заканчивают.
Так что же, метрики — ужас и западня? Они могут быть западней. Но выход — не привязывать ЗП сотрудников к метрикам. Метрики нужны, но лишь для анализа ситуации, как доп. информация.

А если не послушаетесь, то получите:
Букет ненужных последствий, полученных из-за желания следовать KPI (дать водилам автобусов метрику по прибытию на остановки вовремя, и они забудут про сервис и уважение, будут тупо ездить по времени).
Мошенничество и приписывание. И ничего ты не сделаешь с этим, п.ч. у сотрудника 8 часовой рабочий день, чтобы придумать как лучше перестать быть винтиком в твоей тупой машине, и получать максимальный профит в дырявой системе метрик. Никакая система метрик не победит сотрудников, если ты ставишь ее на первое место, а не твоих же сотрудников.
Конфликты там, где они не должны быть. П.ч. метрики одного отдела будут конфликтовать с метриками другого отдела. Например, продажники — дерутся за объем продаж. И им не нужно качество твоей работы по большому счету.

3. Управление человеческими ресурсами

biomassa

Понятие-то какое — человеческие ресурсы, биомасса ить. Лучше бы писали — работа с людьми, человечней все-таки.
Понятие эффективности людей, завсегда приятно измерить. Таким образом, получаем тему, связанную с предыдущим топиком — с метриками.
Не нужно замерять эффективность сотрудников (процесс аттестации). По определению, процесс аттестации не может быть справедливым, а значит, он опустошает, дает ложную оценку, заставляет делать не то что нужно на самом деле, тратит энергию в ж-пу.
Если кто-то хочет построить действительно справедливую оценку эффективности сотрудников, поразмыслите над этим:

  • любой из нас считает себя «выше среднего». Ну и как ты будешь обрабатывать эту ситуацию? Низкопроизводительный сотрудник обидится. И кстати, обидится и высокопроизводительный, когда ты поставишь ему 4.3 вместо 5 из 5.
  • эффективность — субъективное понятие. Никакой SMART не поможет, см тему метрик
  • формулирование целей вначале года\квартала — лишает гибкости в середине периода. Значит тут нужны подпорки в виде change mgmt process.
  • цели будут неравнозначными в разных отделах, да и в пределах одного раздела — тоже!
  • огромный объем работы нужно сделать сотрудникам, чтобы пройти все шаги системы аттестации. Помню возглас из зала, где объявляли про введение этой системы — а работать нам когда?!
  • фаворитизм, эффект ореола (когда прошлые успехи\неуспехи влияют на оценку сейчас), дискриминация по возрасту\внешнему виду бла бла..те еще темы

Возможные выходы:
— ЗП выше среднего по рынку, простейшая привязка ЗП к прибылям (это все есть у Пинка)
— взаимодействие и обратная связь менеджера и сотрудника. А не тратить время на заполнение бланков и отчетов.
— позволять сотруднику выбирать себе цели, в рамках возможного

Лирическое отступление о славянском факторе. Некоторые прожженные российские менеджеры скажут, что эти подходы не сработают для славянского менталитета, с его совком и халявой в крови. Действительно, у нас долгая и не очень веселая история. Однако, какого хр.на нам нужно ориентироваться на прошлое, а не брать передовой опыт и учитывая прошлое, адаптировать, находить новые, свои подходы?
Знаю, что в великой ит компании из трех букв, где я работал, меня пошлют на те же 3 буквы. Но даже там, я уверен, можно выстроить прогрессивную, человеко-ориентированную среду. Ну разве что придется уволить 60% менежмента, и потратить лет 20.

4. Остальное

Как стать хорошим менеджером? Да просто, быть нормальным, адекватным человеком:) Интерес к окружающим, общение, гибкость. Поддерживать хорошие отношения, это ведь не бином Ньютона (вообще то сомневаюсь, бином попроще иногда). Хорошую ссылку дала на Кислород гугла.

Модели менеджмента не имеют реальной ценности, а беседы с сотрудниками — имеют. Единственный способ чему то научиться — работать с людьми, а не читать про это.

Принцип Питера — в иерархической структуре, работники поднимаются до уровня своей некомпетентности. И это не лучший вариант для нас, не так ли? Но как я понял, мир еще не придумал, как эффективно справляться с этим эффектом.

Худшее, что может сделать клиент — нанять кого-то (меня), кто будет думать вместо него. Это намек всем нам, консультантам — делаем так, чтобы клиент сам начал думать, а не оставляем его с отчетом и планом действий:-)

И прежде, чем дать совет клиенту, подумай о последствиях:)

Итак, книга к обязательному прочтению и применению, для каждого консалтера и просто манагера.

Оценка:
Сложность чтения: легко
Полезность: высокая
Оценка: 9/10 (не 10, п.ч. в конце книги совсем уж очевидности описаны)

Внедрение процессов и практик

Говорить о процессе внедрения процесса — дело не совсем благодарное. С одной стороны, процессы внедряют пачками, непрерывно, всегда это делали и будут делать. С другой стороны, мало кто осознанно это делает, и тем более по какой-либо методике.

Если у меня спрашивают о полноценном внедрении процесса, то я выставляю только один критерий — внедрение должно осуществляться как проект. Ну и как вы понимаете, в проект можно много чего напихать:)

Ниже — идеализированная схема внедрения процесса:
2015-06-16_proc_impl_full

По центру — основные активности, справа дана временная шкала, чтобы можно было сравнить со следующим вариантом. Звездами выделены ключевые вещи.
Итак, что получаем:

  • Если у нас проект, значит нужна рабочая группа, нужен план и прочие аттрибуты проекта. В плане должны быть прописаны KPI процесса, также ключевые цели, которые должны быть достигнуты в процессе внедрения процесса.
    Лет 5 назад я бы сказал, что план — очень важен. Сейчас так не думаю:) План — это заготовка, база, которая должна постоянно корректироваться.
  • Задачи из плана должны полностью замениться бэклогом задач — по результатам совещаний рабочей группы.
  • Рабочая группа — важнейший момент (все самое важное выделено красной звездой). С момента формирования группы и до закрытия проекта, рабочая группа регулярно встречается, и корректирует ход внедрения процесса. Дело в том, что каким бы смарт разработчик процесса не был, он не предскажет и половины проблем, возникающих в процессе внедрения. Для этого нам и нужны постоянные корректировки.
  • Разрабатывается документация (регламент процесса).
  • По результатам работы группы, и созданному ей бэклогу задач — выполняются мероприятия. Например, поиск и внедрение подходящего инструмента. Согласование соприкасающихся процессов и т.п. Тут могут быть целые под-проекты, и просажена куча усилий.
  • Промежуточные аудиты — в основном построены на прописанных KPI (которые кстати тоже сабжект для корректировок при необходимости).
  • Тренинги для целевой аудитории. Обычно вначале выбирается группа хомячков, все обкатывается на них. Потом тренинг проводится на всей целевой группе. В эту группу не обязательно входит вся компания, думаю это понятно.
    Хорошо, если вам нравится проводить тренинги. Ведь это выступление перед людьми:)
  • Экзамен. Лично мое убеждение — без экзамена сотрудник а) несерьезно относится б) при всем желании фигово запоминает и не проникается темой.
    Единственный минус экзаменов — большой геморрой с внедрением системы экзаменации. Это реально большая отдельная тема.
  • Закрытие проекта — с отчетом, с анализом ошибок.

Это была идеальная картинка (думаю многие смогут еще ее доидеалить, чтобы в космос полететь).

А в жизни в 95% случаях происходит все вот так:
2015-06-16_proc_impl_basic

Т.е., на основе анализа разрабатывается некий документ, который спускается на компанию. Далее, в зависимости от пожеланий бизнеса, процесс может докручиваться, возможно даже с использованием аудитов. Но частенько процесс на бумаге становится неактуальным через 15 минут после публикации, и дальше начинается параллельная жизнь бумажного и реального тигров.
Но обратите внимание на график работ — на такое вот минимальное внедрение потребуется в 3 раза меньше времени.

Какие выводы? Я понимаю, что идеальную схему внедрения нам доведется исполнить в жизни раз 6. Разве что вы работаете в NASA или атомной энергетике.
Поэтому рекомендую отталкиваться от базового варианта, с привнесением компонентов из полного варианта, по ситуации.

А будучи серьезным дядей\тетей, жизненный опыт подскажет что и в какой ситуации вытаскивать наружу, на стол начальству.

Удачи всем нам с внедрением процессов!

PS в статье я делаю допущения по поводу процессов — не углубляюсь в область управления процессом, упоминаю только про KPI процесса, не даю определения и прочее.

Об интеграции замолвите слово или Company integration

Источник фото http://svetlechekblog.ru/post232412418/

Источник фото http://svetlechekblog.ru/post232412418/

Поразительно, как часто такие непростые вещи, как покупка компаний, делаются «запросто и незамысловато». Наверное, есть плюсы в таком подходе, но очевидны и минусы — наступление захлебывается в лавине непредвиденных «случайностей», интегрированные сотрудники работают «не по нашему», финальные расходы отличаются от плановых в разы.

Опишу базовые концепции интеграции компаний, без амбиций на истину в последней инстанции. Воспринимайте пож-та просто как одну из точек зрений, основанных на пусть небольшом, но практическом опыте.

Обсуждение начальных шагов интеграции, в частности юридической и финансовой сторон — находится вне темы этой статьи. Мы поговорим о практических шагах необходимых для последующей, самой важной с моей т.зр. процессной интеграции.

Любая компания базируется на (бизнес) процессах. Например, отдел продаж — имеет процесс продаж, оценки удовлетворенности заказчика и т.д.; отдел ИТ разработки — процесс разработки и тестирования; финансовый отдел — процесс финансовой отчетности ну и т.д.

Поэтому, как проинтегрируем эти процессы, так и поплывем дальше.

Процесс интеграции компаний делится на этапы, ниже приведена одна из возможных схем этих этапов:

  • Initial stage — постановку целей для интеграции, Due Diligence и собственно, заключение сделки
  • Implementation stage — корректировка планов, выполнение интеграции.
2015-05-18_integration

Общий план по интеграции компаний

 Initial stage

Эта стадия больше относится к выяснению коммерческих интересов сторон, уточнению юридических аспектов. Также, на этом этапе, еще перед подписанием документов, должно начаться планирование.

Считаю это важным моментом, п.ч. зачастую планировать начинают, иногда через несколько недель после закрытия сделки. Все это приводит к затягиванию процесса интеграции, теряется фокус и моментум. Итак, прямо на этой стадии необходимо подумать о следующих стадиях, выделить streams и по мере возможности назначить ответственных. Здесь могут быть сложности ввиду конфиденциальности информации. Но все же, если есть возможность, пусть будущие лиды streams уже начинают планировать и разрабатывать список действий на будущее.

Implementation stage

Планы дорабатываются, составляются детальные списки задач для каждой области (streams).

Можно выделить ключевые под-этапы implementation stage:

  • 1-й день после официального объявления об интеграции
    Это важный день — встречают по одежке. Хорошо подготовленное вводное письмо на всех сотрудников, подготовительные действия для последующих шагов.
  • Первые 100 дней интеграции
    Базовые вещи должны быть сделаны — интеграция финансовых потоков, HR, ICT и тд. После 100 дней компания должна быть в состоянии принимать и исполнять проекты материнской компании.
  • Средне-срочные цели (mid-term), например 4-6 мес. для компании в 100-150чел.
    Цели, поставленные бизнесом должны быть выполнены.
  • Долгосрочные цели (long-term), 1-1.5 лет
    Полная интеграция завершена. Включая интеграцию культур компаний, а это дело непростое.

Классически, весь объем работ разделяют на следующие streams:

  • Operation management
  • Finance mgmt.
  • ICT
  • HR
  • Marketing & Sales
  • Production Processes
  • etc.

По каждому stream необходимо назначить лидера и определить рабочую группу. Это может выглядеть так:

Stream name Company-Acquirer представители CompanyName представители Описание stream
Управление компанией   Стратегия, оперативное планирований, постановка целей и контроль выполнения, определение правил работы компании
Оперативное управление Тактика работы над проектами, процессы взаимодействия, процессы разработки и тестирования, документация, поставка и гарантии, модели проектов и контрактов. Модели разработки, градация сотрудников, карьерный и профессиональный рост. Используемые для разработки и контроля средства, системы и тулы.
Оперативное управление   Успешная работа — time reporting, рабочие процессы и тд
Поддержка бизнеса Визы\командировки, обработка входящей\выходящей документации, заказ канцтоваров и др
Финансы   Финансовый анализ, бухучет, инвойсирование, контракты с заказчиками CompanyName и др заказчиками.
HR     Трудовые отношения с сотрудниками, рекрутинг, соц пакет и бонусные программы, прогноз роста з/п и анализ рынка труда
Коммуникации Коммуникация с прессой, информирование сотрудников, организация мероприятий
Marketing & Sales   Продажи, предложения Заказчику, формирование цены.
Брендинг компании, сайт компании
ICT и инфраструктура   Закупка HW, SW, набор тулов, единая сеть, общие сервисы (email, colaboration and communication)
корпоративные порталы, единые системы учета рабочего времени, репортинг, заявки, управленческий учет и т.д.
Process & tools Интеграция процессов, создание портала для CompanyName
etc.  

Дальше, каждый stream должен проработать план, т.е. буквально — что, когда и кем должно быть сделано. В разработке подобных планов пригодятся чеклисты.  Вот пример чеклиста по ICT — ICT integration checklist_example

 

Некоторые из success factors

  • Интеграция — это проект
    Трактуйте интеграцию как полноценный проект, а не одну-две задачи. Проект предполагает проектный подход. Здесь и план проекта, и отчетность, и другие аттрибуты полноценного проекта. Особенно важно управление рисками. По этой теме пишут отдельные книжки.
  • Коммуникация, коммуникация
    Без полноценного информирования на разных этапах target audience — все может загнуться. Собственно, больше всего страдают сотрудники купленной компании. При недостатке информации они чувствуют себя купленным барахлом (может так оно и есть в глазах руководства?)
  • Оптимальное расположение сотрудников
    Хорошо было бы расположить сотрудников из одних и тех же отделов поблизости друг от друга, чтобы был постоянный обмен и убирались барьеры. Как пример — перелоцировать в одно место сотрудников отдела продаж.
  • Ставим точку
    Не забудьте завершить проект интеграции. Вовремя поставленная точка — сэкономит время\деньги\моральный дух. Не нужно перфекционировать, пора покупать следующую компанию:)

Удачных интеграций!

О создании внутренних порталов (Intranet Portal)

intra process0 Проблема и решение

Создание внутреннего  портала  компании, корпоративного  портала , intranet — с этим вопросом сталкивается рано или поздно любая компания, особенно «айтишная».

Обычно, с ростом зрелости, внутри компании создаются отдельные подсистемы, базы данных, процессы разных подразделений. И у всех — разные платформы, технологии. И слабые связи друг с другом. А еще документы компании размазаны по десятку мест и шар. И новости рассылаются письмами, внутри которых ссылки на папки с фотками.

Но для роста бизнеса нужна согласованность во всех разрезах\сферах компании: люди, инструменты, процессы, и даже принципы и культура компании. Нужна интеграция.

Вот тогда приходит понимание, что компании нужна единая точка входа для всех сотрудников. Нужна система, связывающая все подсистемы в единое целое. Нужно единое место для хранения документов компании. И новостной  портал  нужен. В общем — нужен внутренний  портал  компании.

1 Создание  портала 

У меня нет детальной инструкции по созданию внутренних  порталов . И мне кажется, ни у кого не будет.

Дело в том, что внутренний  портал  — это отражение компании во всех ее уникальных аспектах. Даже внутренняя (негласная) культура компании отразится на ее  портале. Конечно же, есть некие общие компоненты, например — база документов, новостной блок, корпоративная wiki и тд. Однако их компоновка, способ представления, интеграция — делается иногда совершенно удивительными способами.

Опишу свое видение принципов создания  порталов. Пусть даже некоторые из них больше относятся к философии, чем к практике.

1.1 Создание концепции

В принципе, базовую концепцию будущего  портала  создать легко. Нужно всего лишь:

  • узнать текущее состояние компании, ее проблемы
  • узнать пожелания ключевых пользователей будущей системы
  • на основе собственного анализа, и высказываний людей (их проблемы и их предложения) — скомпилировать список основных модулей  портала  и их интеграцию

Эти пункты делаются путем опроса людей, проведение аудита. Нужно опросить ключевых людей, из разных отделов, разных уровней и ролей. Лучше всего, составить вначале список основных ролей в бизнес процессах компании, и затем найти под них подходящих людей.

Это очевидный подход, но есть проблема — люди не знают что они хотят на самом деле. Поэтому концепция, составленная только лишь на мнении опрошенных людей будет в лучшем случае удовлетворительной, т.е. посредственной.

Для того, чтобы сделать действительно классную концепцию, ей должен заниматься визионер, человек — видящий будущее, стратегически предугадывая критически важный функционал для пользователей. Вспомните Стива Джобса.

Такой визионер (кстати, дословно переводится как человек, страдающий галлюцинациями) должен обладать способностью продавливать свое видение, приводить аргументы и доказательства, добиваться требуемых ресурсов и поддержки.

1.2 Создание концепции 2

Вы знаете, как создаются большинство инновационных продуктов сегодня? Их воруют из других идей. Человек видит одну идею, вторую, десятую. А потом они вдруг компилятся у него в голове, решая проблему, над которой он бьется.

«Воровство» при создании концепции — это нормально. Понятно, что по сути это не совсем воровство.

Я рекомендую просмотреть текущие дизайны intranet от Якоба Нильсена, см Intranet Design Annual: 2007 (Free Report). Якоб на одном из форумов выложил также в свободный доступ версию за 2010 год, поэтому передаю вам на скачку и этот отчет. А может вы соберетесь с финансами и купите последнюю версию за текущий год?

Анализируйте  порталы  других компаний, примеряйте на свою ситуацию, помечайте удачные решения.

Больше про правильный процесс воровства идей можно почитать в хорошей книге Остина Клеона «Кради как художник.10 уроков творческого самовыражения».

1.3 Реализация концепции

Из всего многообразия функционала, нужно выбрать самые важные features, обозвать все это например «Release 1″, и сконцентрироваться только на функционале, вошедшем в Release 1. Ни больше, ни меньше.

Далее в ход вступает проектный менеджмент. Если вы выберете agile подходы, то детальную спецификацию можно не делать. Лично мне больше нравятся смешанные подходы, классическа + agile. Поэтому рекомендую на первых порах сделать достаточно подробную спецификацию, включая кликабельный mockup — т.е. модель  портала . Благо инструментария на сегодня хватает. Этот mockup очень сильно поможет с продвижением идей  портала  для менджмента  и ключевых людей на проекте. А дальше, со спецификацией в руках и головой на плечах — все дело техники.

Удачи с реализацией!

Король умер. Да здравствует король! Или смерть ISO 9001.

Сейчас редко найдешь среднюю или большую ИТ компанию, не имеющую ISO 9001 сертификата.

Тем не менее, я считаю, что в ближайшей перспективе ISO 9001 умрет для ИТ мира. Почему?

Попытаюсь обосновать.
Читать далее