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

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

На сайтах фирм по внедрению систем автоматизации деятельности предприятий часто присутствует раздел «Истории успеха». Да, об успехах говорить всегда приятно. Но никто и никогда не станет рассказывать о неудачах. Ни сами внедренцы, ни их заказчики. Никто не хочет выносить сор из избы, а тут еще и конкуренция, имидж фирмы.
Однако секрет Полишинеля заключается в том, что только малая толика внедрений систем автоматизации деятельности предприятий (далее систем) заканчивается успешно, остальные либо "умирают", либо требуют дополнительных финансовых и других ресурсов, в том числе, и временных.
Действительно, по данным исследования, проводимого Boston Consulting Group (BCG) только около 30% респондентов оценивают внедрение ERP-системы, как успешное. По данным же Gartner Group проект не выходит за рамки плана в 60% случаев, а данные Standish Group говорят о 16% таких случаев. И хотя у нас в стране точной статистики никто не ведет, нет причин полагать, что картина может сильно измениться в лучшую сторону. Да и собственные наблюдения авторов, к сожалению, только подтверждает эту печальную картину.
Получается, что поставщики услуг по внедрению систем не говорят полностью о реалиях внедрений, в итоге получается обман клиентов. Заказчики же, в свою очередь, делают вид, что верят им.
Таковы правила игры. Пора их менять. Но для этого надо разобраться с причинами, из-за которых проекты терпят неудачу. Что мешает проводить внедрение бизнес-систем качественно и в срок?
В данной статье рассмотрим ситуации, в которых заказчик сам себе оказывает медвежьи услуги. Надеемся, что это поможет ему в дальнейшем их избежать.

Цели внедрения

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

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

• Цели не сформулированы и не зафиксированы.

Результат:

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

Организация внедрения

Любой проект, в том числе, и внедрение автоматизированной системы, должен быть подкреплен организационно.
Для начала следует создать команду по внедрению во главе с человеком, который обычно является либо исполнительным директором, либо IT-директором, либо CIO (Chief Informational Officer). Руководитель команды должен обладать правом принимать решения по вопросам, касающимся проекта внедрения. В случаях, когда он не в состоянии это сделать, решение должен принимать ЛПР. Область компетенции руководителя группы должна быть также документально зафиксирована.

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

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

• Не создана команда по внедрению.
• Приоритет внедрения не определен или низок.
• Решения не фиксируются документально.

Результат:

• Внедрение происходит по остаточному принципу.
• Невозможно определить ответственных за внедрение лиц.
• Невозможно управлять процессом внедрения.
• Увеличение сроков внедрения и, как следствие, расходов.

Кто будет описывать и анализировать бизнес-процессы?

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

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

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

Результат:

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

Модель процесса всем понятна?

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

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

• Сотруднику компании непонятно описание процесса, но он подтверждает «адекватность» модели, что называется, не глядя, веря на слово тому, кто описывает процесс, под неявным давлением авторитета этого человека.

Результат:

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

Анализ процессов с последующей оптимизацией должен быть

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

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

• Отказ от оптимизации процессов

Результат:

• Итогом автоматизации неоптимизированных процессов будет «автоматизированный хаос».

Когда оптимизировать процессы?

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

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

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

Результат:

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

Оптимизация должна быть обоснованной

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

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

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

Результат:

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

В погоне за новыми версиями

Бывает, что при оптимизации внедренцы часто используют такой вот мифический аргумент про версии своего продукта: систему не следует изменять сильно, а лучше изменить бизнес-процессы предприятия под систему, потому что будут новые версии продукта и переход с одной версии на другую сложнее производить для модифицированной системы.
Скажем так, что аргумент этот очень спорный. Действительно, обычно внедрение системы занимает от 6 месяцев до 1-2 лет. Выход новых версий происходит примерно раз в 1-2 года. Мировая практика показывает, что переходы на новые версии программного обеспечения компании осуществляют в среднем раз в 5 лет.
Таким образом, переход на новые версии либо сделает проект внедрения «вечным», либо, с учетом такого большого срока (5 лет), а, следовательно, и серьезных изменений в программном обеспечении, проект будет приравнен к полноценному внедрению НОВОЙ системы.

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

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

Результат:

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

Что будем автоматизировать?

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

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

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

Результат:

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

Кто будет писать техническое задание?

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

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

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

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

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

Результат:

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

Нужен обоснованный план внедрения процессов и автоматизации

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

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

• Нет обоснованного плана внедрения оптимизированных процессов.
• Оптимизированные процессы не внедряются до внедрения автоматизированной системы.
• План внедрения системы не связан с планом внедрения оптимизированных процессов.

Результат:

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

Выбор программного обеспечения

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

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

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

Результат:

• Выбранное программное обеспечение не способно удовлетворить потребности компании.
• Проект внедрения становится «черным».

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

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

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

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

Результат:

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

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

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

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

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

Результат:

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

Мотивация сотрудников при внедрении автоматизированной системы в эксплуатацию

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

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

• Не разработан обоснованный механизм мотивации сотрудников на этапе внедрения системы.

Результат:

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

Изменения неизбежны, но нужен порядок их обработки и регламент общения между заказчиком и внедренцами

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

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

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

Результат:

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

То, что вам нужно, существует

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

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

• Адекватное описание бизнес-процессов.
• Обоснованная оптимизация бизнес-процессов.
• Обоснованное формирование полного и непротиворечивого технического задания.
• Согласованное внедрение оптимизированных процессов и разработанного программного обеспечения.

Но нужны люди, которые являются носителями таких технологий и которые могли бы на практике их применять. Настоящих профессионалов в области моделирования процессов, их модификации, постановке задач практически нет. Несмотря на актуальность проблемы, ни один ВУЗ не обучает этому, только отдельные компании.
Наиболее близко к подготовке специалистов по указанным направлениям подошла исследовательская группа «Файсом Лаборатория» под руководством российского разработчика А. Г. Тысленко. Группой разработана TAG-технология, в основе которой лежат стандартные методы анализа, позволяющие обоснованно и доказательно разработать оптимальные для компании процессы и обеспечить полноту функций управления. Но и эта группа, к сожалению, не развивает широко это направление и не проводит массового обучения. Материалов по этой технологии в свободном доступе тоже, к сожалению, мало.

Что делать?

Видимо, настоятельным требованием должно быть решение следующих проблем:

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

Самое главное – это возникновение предпосылок для осознанного и комплексного сотрудничества заказчиков, постановщиков и разработчиков автоматизированных информационных систем.

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