"Мы сделаем Вам красиво", - утверждают внедренцы. Но сумеют ли? Почему внедрения автоматизированной системы управления предприятием не завершается, как планировалось.

История вопроса

Что делает компания, которую мы далее будем называть заказчиком, когда хочет автоматизировать свою деятельность? Правильно, определяется с тем, что и за сколько денег она будет это делать. А потом определяется с тем, кто это будет делать. Бывают разные случаи, но чаще всего компания-заказчик обращается в другую компанию, которая специализируется на автоматизации, и которую мы будем называть далее внедренцами.
И все бы хорошо, да вот факты – вещь упрямая. И говорят они нам, что только от 16 (Boston Consulting Group) до 30 (Standish Group) процентов проектов внедрения автоматизированных систем можно считать успешными. А вот по данным Gartner Group процент успешных внедрений достигает отметки в 60 процентов. Можно соглашаться с ними, можно не соглашаться, но факт – у заказчика не может быть уверенности в том, что именно он попадет в число «счастливых» процентов. ПОЧЕМУ???

Все без исключения внедренцы в один голос утверждают, что именно они, если возьмутся, справятся с проектом в нужные сроки. Ну, тут больше политики, внедренцы делают вид, что все сделают, заказчики делают вид, что им верят. А куда им всем деваться-то? Такова правда жизни, к сожалению. Это не вина заказчиков и внедренцев. Это их беда. Так что же делать? Искать ошибки и избегать их.
В настоящей статье нас интересует ситуация с точки зрения внедренцев. Рассмотрим, почему и какие ошибки они могут допустить, и к чему они (ошибки) могут привести. Предупрежден – значит вооружен.

Использование методологии при обследовании предприятия – хорошо, но еще нужны технологии.

Многие внедренцы практикуют в своей деятельности такую услугу как обследование предприятия с целью написания Технического задания, естественно, за деньги.
Не говоря о том, что в этом случае происходит «притягивание» бизнес-процессов предприятия к конкретному программному обеспечению (далее, ПО, система), остановимся на том, КАК происходит такое обследование.
Читая многочисленные «истории успеха», редко можно встретить слова о ПОЛНОЦЕННОМ обследовании бизнес-процессов заказчика и их оптимизации. Более того, никто и никогда не упоминает о применяемой технологии обследования предприятия и внедрения. Что бы это значило? То, что технология внедрения каждой компании по внедрению уникальна и не отчуждаема? А может, ее и нет вовсе?
Фирмы-внедренцы говорят везде, где только можно, о применяемых методологиях. Но не о технологии. Результаты, полученные с помощью технологии, повторяемы. Почувствуйте разницу…

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

Типичные ошибки:

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

Результат:

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

Откуда аналитики берут информацию?

В процессе сбора информации о бизнес-процессах обычно применяются две формы – анкетирование и интервьюирование.

Анкетирование – вещь полезная. Но этот метод может рассматриваться только в качестве метода сбора предварительной информации, которая есть только повод для разговора, не более. У каждой компании своя специфика, нельзя в анкете предусмотреть все нюансы. Поэтому применение только этого метода не может дать полной информации о бизнес-процессах.
Вот что сами исследователи говорят о процессе сбора информации (VisionPeople №1 2001, и если Вы думаете, что что-то изменилось с 2001 года, то это иллюзия): «Необходимые исследования выполнялись в форме последовательных дискуссий, сначала с высшим руководством, а затем со всеми ключевыми работниками. Диалог помогает растопить лед и создать взаимное доверие». Насчет последнего спорить никто не будет, а вот кто такие ключевые работники? А как быть с неключевыми? Как вообще определить, является работник ключевым или неключевым? Кто сортирует сотрудников и на основании чего? И почему такая уверенность, что высшее руководство досконально знает все бизнес-процессы предприятия? А что в итоге? Читаем дальше: «Отчет по диагностике включает множество диаграмм, описывающих бизнес-процессы клиента. Они помогают не только находить проблемные области, но и предлагать решения». Опять вопрос: КАК? Или к этому делу привлекается очередной «гуру»?
Итак, первый вопрос в том, кого надо опросить? Напрашивается вывод: надо опрашивать всех сотрудников, участвующих в бизнес-процессе, хотя бы на уровне должностей? И если несколько человек имеют одинаковые должности, то кого из них выбрать? А как определить, кто в каком бизнес-процессе участвует? И еще очень интересный вопрос: с кого начать? А вдруг кого пропустим?

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

Типичные ошибки:

• Использование для сбора информации только анкетирования.
• Необоснованный выбор сотрудников для интервьюирования.

Результат:

• Неполная информация, использование которой дает неадекватные модели бизнес-процессов.

Собранная информация не проверяется на противоречивость и полноту

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

Типичные ошибки:

• Нет обоснованного анализа получаемой информации о бизнес-процессах с точки зрения полноты и непротиворечивости.

Результат:

• Собрана некачественная информация, использование которой дает неадекватные модели бизнес-процессов.

Результат моделирования неповторяем

Анализируя собранную в процессе анкетирования и интервьюирования информацию, аналитик моделирует (рисует) бизнес-процессы. Как? Как получится? Это же творчество (чувствуете сарказм?). Нет четких правил такого описания.
Представим себе ситуацию, когда на одном и том же проекте независимо друг от друга работают два аналитика. И пусть они работают на адаптацию и внедрение одной и той же системы. Более того, пусть они применяют одну и ту же методологию, а также одни и те же средства моделирования. Вы можете поверить, что модели процессов, которые они создадут, совпадут? Верится с трудом.
А теперь представим себе, что оба аналитика приходят к лицу, принимающему решения, в том числе, и по поводу автоматизации, со своими моделями. Первый естественный вопрос: почему они разные? Второй вопрос: какая модель правильная, какую выбрать для дальнейшего использования?
Видимо, дело в методологиях и средствах описания процессов. Есть методология. Очень хорошая сама по себе. Основной вопрос: как ее применять?
Возьмем, например, описание бизнес-процессов. Есть множество замечательных рисовалок типа ARISа или BPwin’а. Есть еще Rational Rose. А есть еще Visio и PaintBrush, тоже красиво получается. В ценности методологий, которые поддерживают первые три, не приходится сомневаться. За исключением вопроса: почему у всех получаются разные результаты? Нет ответа. А это означает, что аналитики принимают необоснованные решения.

Типичные ошибки:

• При моделировании бизнес-процессов принимаются необоснованные решения.

Результат:

• Результат описания бизнес-процессов неповторяем, есть риск получить неадекватные описания бизнес-процессов.

Используемая нотация непонятна заказчику, или к чему приводит утверждение "непонятных" моделей

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

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

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

Типичные ошибки:

• Заказчику не доводится ПОЛНАЯ информация  об используемой в моделях бизнес-процессов нотации.
• Использование нотаций, для понимания которых заказчику требуется пройти дополнительное обучение.

Результат:

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

Заказчик про Фому, внедренец про Ерему, или почему надо использовать один и тот же понятийный аппарат

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

Типичные ошибки:

• Нет глоссария используемых понятий.

Результат:

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

Процессы под автоматизацию. Оптимизация или изменение?

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

Типичные ошибки:

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

Результат:

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

Новая версия или успешное внедрение. Что выбрать?

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

Типичные ошибки:

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

Результат:

• Ранее поставленные цели внедрения могут быть не достигнуты из-за необоснованных изменений бизнес-процессов.

Автоматизируем все подряд?

Все знают, что программистов хлебом не корми, дай что-нибудь запрограммировать. И внедренцы туда же. Оно и понятно. Чем больше объем работ, тем больше заказчик заплатит за него. А как проверить, что заявляемый объем работ необходим? Может, часть работ и не надо вообще автоматизировать? Вот и вопрос: как и на основании чего выделить операции бизнес-процесса для автоматизации?
Для решения этого вопроса нужно применение обоснованных методов. Кроме того, применяемые модели процессов должны позволять провести такой анализ.
Или список процессов и операций для автоматизации заказчик должен озвучить? А знаете ли Вы, что часто заказчик просит и даже требует автоматизировать неустоявшиеся процессы. А это означает ПОСТОЯННОЕ изменение требований, что, в свою очередь, влечет увеличение времени внедрения. Тем самым проект оказывается вечным. Может ли он считаться успешным? Вопрос риторический.
А как определить, устоялся процесс или нет? Для этого необходимы критерии, которые позволяют это сделать.

Типичные ошибки:

• Необоснованное выделение операций процессов для автоматизации. Отсутствие критериев выделения. Модели процессов не позволяют применять для этого формальные методы.
• Попытка автоматизировать неустоявшиеся процессы.

Результат:

• Увеличение времени проекта внедрения. Проект становится «вечным».
• Цели проекта не достигаются.
• Эффект от внедрения может привести к падению эффективности деятельности компании.

Техническое задание должно быть полным, непротиворечивым и достаточным для утверждения

Одним из следствий вольного применения методологий при описании процессов является нарушение уровня детализации описаний процессов. В итоге это нарушение транслируется в требования к программному обеспечению, что не может не сказаться на воспринимаемости их как для заказчика для утверждения, так и для конкретных исполнителей со стороны внедренца.
Вольность при описании бизнес-процессов может явиться также причиной противоречивости моделей процессов, что приводит к противоречивому техническому заданию. Как проверить техническое задание на полноту и непротиворечивость? Судя по статистике внедрений, почти никто этого не делает. Или не может сделать, так как инструмента для этого нет?
В итоге у заказчика не может быть уверенности в том, что техническое задание адекватно описаниям процессов. Более того, у самого внедренца не может быть такой уверенности.

Типичные ошибки:

• Нарушение уровня детализации при описании процессов и написании технического задания.
• Фиксация противоречивых  и неполных требований в техническом задании.
• Заказчик и внедренец вынуждены утверждать непроверенное техническое задание.

Результат:

• Получение неадекватного процессам технического задания.
• Цели внедрения не достигаются.

Разбивка функциональности на модули и последовательность их внедрения

Почему-то многие внедренцы указывают некую последовательность этапов внедрения, которая, вообще говоря, непонятно, откуда взялась. Очень часто основной упор делается на внедрение в первую очередь модулей по управленческому учету. Оно и понятно: постановка грамотного учета на предприятии – это то, ради чего обычно и затевают внедрение системы. А на основании чего этот самый учет будет работать? Откуда брать фактический материал? Очевидно, что без внедрения блоков по сбору первичной информации (хотя бы приход и расход товара) ни о каком управленческом или ином учете и речи быть не может. Это обстоятельство надо учитывать при разработке детального плана внедрения. Естественно, что каждый внедряемый блок, или модуль, должен «черпать» информацию из уже внедренных.
Так как внедрение автоматизированной системы не может быть не согласовано с внедрением оптимизированных или измененных процессов, то естественен вопрос о разбивке функциональности на модули или блоки, которые внедряются на каждом этапе.
Сама по себе разбивка функциональности на блоки, или модули, часто соответствует блокам в стандартной поставке системы внедренца, и почти никогда не соответствует бизнес-процессам. Имеется в виду не только собственно разбивка, но и взаимосвязи блоков.

Типичные ошибки:

• Необоснованное деление, или разбивка, функциональности создаваемого программного обеспечения на модули, или блоки. Часто – в соответствии с существующими блоками в стандартном программном обеспечении.
• Необоснованная последовательность внедрения автоматизируемых блоков.
• Рассогласование внедрения автоматизируемых блоков и блоков оптимизированных процессов.

Результат:

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

Архитектор в облаках, или проблема проектирования

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

Типичные ошибки:

• Принятие необоснованных решений при разработке архитектуры системы.

Результат:

• Разработанное программное обеспечение не соответствует реальным процессам.

Программисты фантазируют по-своему

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

Типичные ошибки:

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

Результат:

• Созданное программное обеспечение не соответствует техническому заданию и реальным процессам в компании.
• Сопровождение программного обеспечения становится очень трудоемким.

Документации пользователя нет. Обучения тоже

Для успешного начала работы с новой системой на местах пользователи должны знать, что и как им делать.
Для этого обычно проводят обучение. Но часто это обучение сводится к обучению работе со стандартной системой, а не с той, которую внедряют в компании. Безусловно, пользователей необходимо обучать основам работы с системой. Например, как и где ввести пароль, как наложить фильтры на записи и т.п. Но кто им расскажет, как им выполнить операции процесса, в котором они участвуют?
Кроме того, возникает вопрос о том, как обучать вновь пришедших сотрудников. Вряд ли из-за одного человека имеет смысл заказывать полноценное обучение у внедренца. Решение-то есть – это полноценная инструкция пользователя. Естественно, необходима также документация по стандартной системе. С этим вопросов нет, а вот с инструкцией пользователя могут возникнуть проблемы. Чтобы ее написать, необходимо очень четко представлять, что, когда и как делает тот или иной сотрудник. Ясно, что без адекватного описания бизнес-процессов предприятия такую работу качественно выполнить не удастся.

Типичные ошибки:

• Обучение пользователей не проводится или проводится только для стандартной системы.
• Документация пользователей не готовится.
• Документация пользователей готовится неадекватно бизнес-процессам.

Результат:

• Сопротивление сотрудников внедрению вплоть до саботажа.
• Внесение пользователями ошибочных данных в базу данных системы.
• Увеличение времени внедрения.
• Падение эффективности работы всей компании.

Тесты. No pasaran?

Существует множество видов тестирования, которые определяются целями тестирования. Это может быть нагрузочное тестирование, тестирование с целью локализации уже выявленных ошибок и т.д.
Что касается тестирования при разработке, то оно безусловно нужно. Для его организации необходимы полные требования к программному обеспечению. Где их взять? Из технического задания и из документа, содержащего детальные требования к системе. Когда их готовить? Как показывает практика, в случае составления тестов до начала разработки многие ошибки, пропущенные ранее, выявляются. Так что, с одной стороны, обнаруживаются нестыковки в техническом задании, а, с другой стороны, готовые тесты служат дополнением к требованиям. Хорошее подспорье для разработчиков. К сожалению, очень часто процесс тестирования поставлен крайне плохо, если не сказать больше. Многие попросту экономят на тестерах, а зря.
Но есть еще тестирование при приемо-сдаточных испытаниях программного продукта. Без тестов не обойтись. Иначе как заказчик может принять систему.
Вопрос в том, кто должен готовить тесты для таких испытаний? А главное – на основании чего?
Ответ на первый вопрос может быть такой, что готовить тесты должен заказчик, а вот помочь ему в этом должен внедренец. Отдельная тема, как и кто будет это делать. Другое дело, что внедренец требует тестов от заказчика только ближе к концу разработки, а тот их дать не может. Или дает, но они не «проходят» у внедренца. В чем причина? Во взаимодействии? Да, но не только и не столько. Дело может быть в некачественном техническом задании, а может и в том, что заказчик им не пользуется, а чаще всего и в том, и другом.

Типичные ошибки:

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

Результат:

• Некачественное программное обеспечение.
• Программное обеспечение, не соответствующее техническому заданию и бизнес-процессам.
• Цели проекта внедрения не достигаются.

Интерфейсы. Как бы мне, рябине, к дубу перебраться…

Многие разработчики знают, что сопряжение разным программных продуктов – серьезная, трудоемкая задача, при которой необходимо учитывать особенности функционирования сразу нескольких систем, форматы данных, а главное – что, когда, куда и каким образом должно передаваться. Кроме того, существует проблема некорректных с точки зрения бизнес-логики данных, которые возникают по разным причинам то в одной сопрягаемой системе, то в другой. В итоге происходит «размножение» ошибок по базам данных. А их потом ведь исправлять надо…
При больших объемах данных могут возникнуть проблемы с блокировками данных, недостаточной скоростью обработки и т.п. Такие проблемы могут помочь выяснить нагрузочные тесты. Вообще, вопрос с тем, как тестировать интерфейсы – это отдельная песня.
Однако часто при внедрении бизнес-систем вопросу взаимодействия разных программных средств не уделяется должного внимания, а в техническом задании просто стоит фраза из серии «Необходимо организовать передачу товарных остатков из базы данных филиалов в базу данных центрального офиса». Очень хорошо для формулирования общего требования, но не для детального требования, а его-то как раз и нет.

Типичные ошибки:

• Требования к интерфейсам между сопрягаемыми системами неполные или присутствуют в самом общем виде.
• Отсутствие проверок на корректность передаваемых и получаемых данных.
• Разработанный регламент взаимодействия систем посредством интерфейсов не соответствует бизнес-процессам.
• Отсутствие или плохо организованный процесс тестирования интерфейсов.

Результат:

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

Про изменения требований

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

Типичные ошибки:

• Необоснованное изменение требований к программному обеспечению.
• Отсутствие фиксации факта и самого изменения бизнес-процесса.
• Отсутствие фиксации факта и самого изменения требования к программному обеспечению.
• Отсутствие регламента сообщений об изменениях требований к программному обеспечению.

Результат:

• Программное обеспечение не соответствует техническому заданию и бизнес-процессам.
• Сопровождение программного обеспечения затруднено.

Про оценку времени внедрения

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

Типичные ошибки:

• Необоснованные расчеты времени по проекту.
• Использование в расчетах неполных и/или противоречивых данных из технического задания.

Результат:

• Срыв сроков внедрения.

На поставленные вопросы должны быть ответы

Это был неполный список проблем, с которыми внедренцы сталкиваются в процессе внедрения автоматизированных систем деятельности предприятия.
Но все они сводятся к тому, что для успешного внедрения необходим специальный аналитический аппарат для описания, анализа и оптимизации бизнес-процессов, который может дать технология, но не методология.
И только применение жесткой технологии позволяет устранить неоднозначности и противоречия в описании процессов, техническом задании, а, следовательно, и в требованиях к программному обеспечению.
К сожалению, специалистов, которые были бы носителями таких технологий и могли бы применить их на практике, были бы профессионалами в области моделирования процессов, их модификации, постановке задач практически нет. Парадоксально, но в ВУЗах готовят сонмы программистов, но не готовят указанных специалистов. Молодые специалисты умеют писать программы, то есть код, даже разрабатывать алгоритмы, а вот грамотно ставить задачи программистам не учат. Попробуйте найти в Интернете информацию о том, как правильно писать техническое задание. Ничего толкового, кроме ссылок на ГОСТ 34.602-89 вы не найдете. Но найдете целую кучу ссылок на форумы, где народ до сих пор не может найти ответ на это, казалось бы, простой и понятный вопрос «Как писать ТЗ?».
К сожалению, объективно сложилась ситуация, что ни одна версия ТЗ не является одновременно «прозрачной» и для заказчика и для разработчика.
И дело, как показывает практика, не в форме ТЗ, а в отсутствии методологии или, тем более, технологии создания ТЗ, связно и целостно отражающего цели и задачи автоматизации. Как ни парадоксально, но в настоящее время в мировой практике до сих пор нет даже попыток создания подобных технологий. Отдельные удачные исследования (в том числе TAG-технологис, Hollis Instruments) недоступны для широкого круга пользователей. Остается надеяться на то, что рано или поздно на рынке услуг IT-индустрии появятся компании, заинтересованные в том, чтобы закрыть эту брешь – тем перспективнее будут возможные решения.

А. Стрельников,
ведущий IT-специалист "Агама Групп"
ноябрь 2005 г.