Детальное ТЗ – ловушка для начинающих

“У любого проекта может измениться план, однако у ИТ-проекта это происходит настолько часто, что каскадные методологии управления становятся препятствием реализации проекта.”

Автор: Мартынов Дмитрий. Кодер Лоджик.

Уже общим местом стало высказывание, что внедрение ERP-системы меняет бизнес процессы. Что ни статья или высказывание ИТ-эксперта, обязательно «невозможно внедрение системы без изменения процессов» или «изменение процессов наверняка произойдет, и это надо планировать заранее». Не цитирую источники, ибо имя им легион. Тут еще важно то, о чем эксперты обычно не говорят: процесс изменяется непредсказуемо. Ну кто же признается в том, что не контролирует происходящее, так можно и контракта лишиться. Одна показательная история многое объясняет.

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

Так вот… Одна замечательная компания в процессе роста из малого предприятия в средние затеяла внедрение ИТ-системы для учета и управления.

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

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

Мог ли в первоначальное ТЗ попасть сброс резервов? Ну если там не было резервов, то откуда взяться сбросу. Может быть, консультанты сплоховали? Да нет уж, письмо, разъясняющее преимущества резервирования, было… Хотя в конце все получилось не так, как описывалось в письме. Можно ли было все предсказать заранее? Теоретически… Теоретически при современном развитии технологий человечество давно должно было иметь колонии на Марсе, практически этого не происходит, увы. И тут похожая история.

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

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

Почему же все так непредсказуемо?

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

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

Меня всегда забавляет задание на ИТ-систему, которое начинается с задач планирования. Давайте начнем с учета, ведь планирование будет эффективным, если оно будет опираться на достоверные данные. А в процессе отладки учета может вылезти столько изменений к первоначальному заданию, что упомянутые в нем идеи планирования будут оторваны от реальности.

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

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

В области ERP-систем наиболее используемым методом управления стал Scrum.

Здесь накоплено большое количество практики и есть много хорошего материала.

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

1. Стандарт scrum подразумевает очень короткие спринты (этапы), которые не позволяют на проекте ERP проконтролировать промежуточный результат.

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

2. Меньшая определенность стоимости проекта.

А это совсем не недостаток. Фиксированная стоимость проекта – иллюзия, которая однажды может ударить по голове того, кто не был к этому готов.

Пожалуй, все. Не стоит забывать, что кроме выбора методологии и готовности часто менять задание существует масса других вопросов, от которых зависит результат. Удачный выбор ИТ-системы, правильное построение взаимоотношений с интегратором, мотивация собственного персонала на результат и др. Но все это темы других статей, и они у нас есть. Читайте и внедряйте!

[evc_social_likes]