Журнал «Компьютерра» № 8 от 28 февраля 2006 года - Компьютерра

— Да кто вас боится! — сказала Алиса (она уже достигла своего настоящего роста). — Вы просто несчастные карты — и все!

2.1. Описание бизнес-процессов

Принимая описание бизнес-процессов (БП), Заказчик хочет увидеть документ, в котором правильно описаны бизнес-процессы, указанные в договоре (иногда их даже забывают записать в договор — всякое бывает).

Когда главная цель — понравиться, у Исполнителя остается большое поле для маневра. Например, в описании бизнес-процессов важна детализация. Большинство бизнес-процессов кроме основной ветки развития включают в себя и другие, дополнительные ветки, которые происходят реже, но все же происходят. К примеру, в процессе производства (основная ветка) может обнаружиться брак, может быть выявлена ошибка конструкции, на склад недопоставят необходимый материал, ценный специалист, без которого не запустить определенное оборудование, может заболеть и т. д. Без учета этих ситуаций описание бизнес-процессов будет неполным, а значит, его нельзя использовать для решения задач Заказчика (точнее, можно, но ровно до тех пор, пока не случится нештатная ситуация).

Обычно Исполнитель хотя бы часть дополнительных веток БП описывает. Но часто Заказчик не замечает, что некоторые ветки были упущены. Это может происходить по нескольким причинам, часть которых является следствиями ошибок, допущенных на этапе формирования проектной команды Заказчика:

1. Специалистами Заказчика, ответственными за приемку работ, являются ИТ-специалисты, и их квалификации недостаточно для оценки качества документа.

2. Ответственность своих специалистов оценивается Заказчиком неадекватно. То есть человек, принимающий основные решения по проекту общей стоимостью 500 тысяч долларов, может иметь зарплату 1 тысячу долларов.

3. Ответственность за результат работы отодвинута во времени на длительный срок. Если описание БП будет неправильным, это станет заметно только через несколько месяцев.

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

5. Компетентные специалисты Заказчика не любят сбои в работе процесса, так как несут за них реальную ответственность. Если в описании БП такой сбой не будет описан, это произведет благоприятное впечатление на подсознательном уровне.

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

Если при правильной организации приемки работ с причинами 1, 2, 4, 5, 6 можно и нужно бороться, то причина 3 является неотъемлемой частью этапа описания БП.

В результате получается документ, качество которого не соответствует потребностям проекта. Несмотря на это у Исполнителя не возникает проблем с закрытием этапа по указанным выше причинам.

2.2. Техническое задание на проект

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

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

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

2.3. Настройка системы, описание доработок

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

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

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

2.4. Доработка системы

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

2.5. Обучение (свет в конце тоннеля)

Этап может принести большую пользу Заказчику в смысле контроля за подготовкой проекта. Для этого обучение пользователей должно проводиться на настроенной системе, в которой выполнены доработки.

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

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

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

2.6. Зачем такой длительный предпроект?

"Позвольте, мамаша! На станции,

Согласно багажной квитанции,

От вас был получен багаж:

Диван, чемодан, саквояж,

Корзина, картина, картонка

И маленькая собачонка.

Однако во время пути

Собака могла подрасти!"

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

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

Когда будет выполнено все, кроме последнего этапа, нет гарантий, что полученная система сможет быть внедрена. Для Исполнителя важно, что почти все деньги получены. Если последний этап выполнить не удается, то для Исполнителя в этом нет ничего страшного. Риски незначительны. Он рискует:

< Неполученным остатком денег из бюджета проекта.

< Своей репутацией.

< Невыполнением обязательств по договору.

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

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

2.7. Внедрение

Последний этап обычно очень сложен. Прежде всего из-за низкого качества выполнения задач предпроекта. Но есть и другая причина.

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

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