ПОДВОДНЫЕ КАМНИ

Олег Токарев, Senior Project Manager о профессиональном подходе к управлению проектами.

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

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

Методология внедрения и планирование проекта.

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

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

Методология внедрения - это гораздо больше чем план проекта. Методы Управления проектом, такие как решение проблемы управления рисками, управление изменениями, управление качеством, формальная приемка результатов, предоставляют мощную основу для успешного проекта.

Формирование проектной команды.

Нередко именно этот фактор приводит внедрение системы к провалу. Причины:

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

Как мы решаем: Сотрудники нашей компании являются квалифицированными специалистами как в технической области, так и в сфере консалтинга складских бизнес – процессов, также наши руководители проектов являются универсальными специалистами, которые контролируют любую работу на проекте, от качества описания бизнес – процессов, до настройки оборудования. Одним из важнейших преимуществ нашей методологии внедрения, является четкое определение ролей каждого участника проекта, каждому определяется свой перечень работ, за которую он несет ответственность. Для описания бизнес - процессов в команду включаются сотрудники, знания которых позволяют максимально полно и качественно описать процессы: конечные пользователи, логисты, товароведы, начальники склада. При формировании проектной команды проводится проверка квалификации технических специалистов Заказчика занятых на проекте.

Недостаточное участие заказчика (спонсора) проекта.

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

Обучение конечных пользователей.

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

Как мы решаем: При обучении мы используем подход «подготовки инструкторов» Заказчика или «обучение обучающих», т.е. обучение производят специалисты заказчика совместно с нашими тренерами, как результат, в последствии Заказчик сам сможет обучать новых сотрудников компании. Для каждого клиента мы разрабатываем инструкции на каждую операцию в системе. После обучения ведущим руководителем проекта проводится экзаменация пользователей, с выдачей именных сертификатов.

Оптимизация бизнес – процессов.

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

Как мы решаем: Первоначально проводится фаза сбора информации. Составляется перечень операций, производимых на складе компании и вопросы (например, какой лучший путь приемки товаров, возможен ли прием товаров с использованием радиотерминалов или автоматический прием товара, какие оптимальные правила оборачиваемости товара на складе, возможно ли в текущем процессе использовать операции сквозной отправки («с колес на колеса»), если нет, что нужно изменить, чтобы их можно было бы использовать, комплектации заказов оптимален для склада, например – ручная комплектация, комплектация с использованием радиотерминалов, комплектация с использованием этикеток, пакетная комплектация, лучше оптимизировать использование рабочего времени работников склада, управление запасами товаров на складе и отчетность по запасам на складе), на которые предстоит ответить совместно компаниям Заказчика и Исполнителя для приведения складских процессов заказчика к виду, позволяющему достичь максимального эффекта. Для каждого из вопросов будет определен текущий бизнес-процесс, описаны создаваемые при этом документы, потоки товаров и информационные потоки. Результатом этой фазы является документ AS IS (как есть).

На следующей фазе TO – BE, совместно со специалистами компании Заказчика будут выработаны рекомендации, согласно которым можно оптимизировать эти процессы. Результатом этой фазы является документ TO BE (как будет), в котором очень подробно описаны и рекомендации по бизнес – процессам и как будут эти процессы реализованы в системе. Документ согласуется со специалистами Заказчика.

Расчет мощности серверного оборудования.

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

Как мы решаем: На начальном этапе собирается статистическая информация, о количестве пользователей, количестве выполняемых операций за сутки, процент коробочного отбора, перспективы роста компании и т.д. Данная информация отправляется разработчику программного обеспечения, который рассчитывает рекомендуемую конфигурацию и количество серверов (кому как не разработчику это знать).

Наш опыт.

• Переход от бумажной технологии к RF. Внедрение системы у одного из наших первых клиентов должно было быть осуществлено в кротчайшие сроки, уже через 2 месяца на склад должен был заехать клиент, договор был уже подписан. В условиях таких жестких временных ограничений (обычно срок внедрения 3 месяца) необходимо было предпринять решение, которое бы позволило снизить риски при внедрении системы. Решение было найдено, на момент запуска отбор осуществлялся по бумажной технологии, поскольку для РЧ – отбора требуется более длительное обучение, да и вообще, сам запуск с помощью РЧ – отбора является более сложным. После успешного запуска, по прошествии 10 дней, технология комплектации была переведена на отбор с использованием терминалов. Тем самым, риски при запуске были сокращены, и в итоге Заказчик получил, то, что было нами заявлено, а именно РЧ – отбор. Таким образом, мы осуществили безболезненный переход с одной технологии на другую, что имеет значение в том случае, если бюджет Заказчика к моменту запуска не позволяет использовать РЧ – отбор, в последствии есть возможность перейти на использование на эту технологию.
• Смена проектной команды. У одного из наших клиентов при внедрении системы была произведена смена проектной команды со стороны исполнителя, т.е. первые две фазы проводил один интегратор, а последующие 5 фаз, в том числе и запуск, компания Логикон. Таким образом, методология внедрения позволяет, без увеличения сроков и качества проекта изменять проектную команду исполнителя, благодаря возможности выхода из проекта на каждой стадии.
• Приостановка проекта. Также одним из ярких примеров, того, что методология позволяет выйти из проекта на любой стадии, является приостановка работ на проекте сроком на 5 месяцев. До 10 октября мы выполнили все работы, касающиеся анализа бизнес – процессов, настройки системы, обучения и т.д. Предполагалось, что к этому времени склад будет сдан, но возникли сложности согласования склада с пожарной службой, которая в итоге затянулась на 5 месяцев, а также затянулись сроки по поставке погрузочной техники. После решения всех проблем в начале февраля наши работы продолжились и в итоге, уже через две недели состоялся запуск работы склада.
• Наш опыт при формировании проектной команды. На одном из наших первых проектов нами при формировании проектной команды была допущена ошибка, заключалась она в том, что мы не провели проверку компетентности сотрудников Заказчика, включаемых в проектную команду. Мы просто включили в команду тех, кого нам порекомендовали. Компания была молодая, все сотрудники только что устроились на работу. В результате, когда начались реальные работы, в которых участвовали эти сотрудники, они просто не справлялись с поставленными им задачами (скажем в вопросах интеграции) или не могли выдать нужную нам информацию. Как результат часть работ пришлось выполнять нам самим, что увеличивало сроки проекта, или на поиск необходимой информации уходило большее время. Теперь же при формировании команды мы проводим достаточно серьезное тестирование технических специалистов, а также для сбора информации включаем в команду работников со всех уровней, т.е. от кладовщика до директора по логистике.
• Требования к заказчику. Порой успешный запуск зависит от того, насколько Заказчик выполняет наши требования, например, предоставить необходимое количество складского персонала, оборудования, компьютеров и т.д. Хотя этот момент может показаться несколько нелогичным, ведь Заказчик сам заинтересован в успехе проекта. Но мы не исключаем вероятность ситуации, скажем, Заказчик не может набрать полный штат на склад, или предоставить все необходимое «железо», поэтому мы на фазе планирования обговариваем все эти моменты и выставляем жесткие требования, ну и естественно, разрабатываем пути обхода данных проблем (например, сокращение товаропотока через склад) все это необходимо для того, чтобы проект был успешен, а не потому, что мы «такие плохие».
• О рисках. Мы на этапе планирования стараемся предусмотреть всевозможные риски которые могут возникнуть в процессе внедрения системы, иногда даже такие: 

1. мы знаем, что к моменту запуска будет очень сильно увеличен товаропоток через склад, в отличии от обычного режима работы (например новогодние праздники), поэтому будет очень сложно запуститься, мы принимаем решение совместно с Заказчиком в самом начале, оценив его и наши силы, либо перенести Запуск на после, либо, наоборот, конечно, если это возможно, реально оценивая ситуацию, сократив сроки проекта произвести запуск заранее. 
2. выход из строя оборудования, например, WI –FI сети, соответственно, терминалы работать не будут, на этот случай, у нас есть все необходимые бумажные операционные отчеты, для выполнения операций.

Конечное, же планируем такие распростаненные риски: 

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

б) банальный выход серверного оборудования из строя. 

в) срыв поставок и т.д. Конечно, же иногда случаются и такие риски, которые мы не запланировали.

Например, после того, как мы установили наше радиооборудование, включили его в сеть предприятия, совместно с местными администраторами, нам позвонил человек из независимой службы безопасности фирмы и сказал, чтобы мы выключили оборудование, как оказалось все новые объекты включающиеся в сеть должны быть согласованы с ним. Нам почему то, никто об этом даже и не сказал, ни руководители IT – подразделений, ни IT – специалисты, конечное же вопрос разрешился, но мы учли этот факт на дальнейшие проекты. Таким образом мы на этапе планирования формируем довольно обширный список рисков и пути их решения. Благодаря нашему опыту, этот список уже очень длинный.