Информационные технологии управления / УМК

311

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

Пример из жизни:

–Петрович (зав. складом), отпусти ―Кентавру‖ (покупатель). Я накладную попозже занесу, не хочу клиента заставлять ждать: берут много, платят налом.

–Нельзя.

–Да ты что? Всегда же так делали.

–А теперь шеф штрафует. Все – через компьютер.

–Во программеры… Дармоеды очкастые. Работать не дают. Разогнать бы! Действовать предлагается не ―по понятиям‖, а по правилам. Для носителей

российского менталитета это всегда тяжелое испытание (―Что я, сам не знаю, как лучше делать?‖).

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

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

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

Техническое задание

Техническое задание – набор документов и спецификаций, определяющих требования к информационной системе и ее функциональности. В него входят:

требования к автоматизированным рабочим местам, их составу и структуре;

разработка требований к программным средствам;

разработка топологии, состава и структуры локальной вычислительной

сети;

требования к секретности и защите информации. Процессы системы делятся на:

ручные (регламентируются, но не автоматизируются);

пакетные (как правило, сбор статистических данных, получение отчетности за период, пересчеты глобальных регистров);

диалоговые (подавляющее большинство процессов в современных АСУП);

процессы реального времени.

Для автоматизированных процессов конкретизируются требования к виду и форме документов.

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

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

312

Технико-экономическое обоснование

Анализ ―затраты-эффект‖ позволяет принимать обоснованные решения и подтверждает финансовую необходимость изменений.

Для систем MRP/ERP козырная карта ТЭО – управление запасами и логистика. В результате внедрения существенно уменьшаются запасы на складах, сокращается цикл производства, исчезает дефицит товаров и комплектующих и т. д. Все эти преимущества имеют строгое количественное выражение (стоимость аренды складских помещений, затраты на перевозки и др.). В результате расчет экономического эффекта становится делом техники и ТЭО выглядит вполне убедительно. В то же время определение и количественная оценка некоторых статей расходов до сих пор вызывает трудности даже за рубежом. Отчасти задача решается методом аналогий.

Менее благополучно дело обстоит с внедрением бухгалтерских модулей. Какую экономическую выгоду получит предприятие, если заменит ―плохую‖ бухгалтерскую систему на ―хорошую‖? Например, повышение качества учета. Адекватная бухгалтерская система ―организует‖ работающего в ней бухгалтера. Знакомясь с учетом клиента, нередко обнаруживаешь сотни фантастических субсчетов (заменяющих аналитику), диковинные отчеты, созданные под мудрым руководством, какой-нибудь Марьи Ивановны. Все это согласовано с представителем налоговой инспекции и гордо именуется ―официальной учетной политикой предприятия‖.

Установка на таком предприятии хотя бы ―1С‖ ведет к уничтожению существующей бухгалтерской ―матрицы‖ и вносит некоторый учетный порядок. Однако единственный аргумент в пользу внедрения – необходимость полностью перестраивать учет в случае ухода ―концептуального главбуха‖.

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

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

–уменьшается вероятности ошибки (особенно если расчеты многовалютные);

–руководство в любой момент имеет доступ к исчерпывающей информации о положении дел;

–существует возможность в режиме реального времени отслеживать должников

исвоевременно принимать меры.

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

Многие так называемые ―точные данные‖ приводятся ИТ-компаниями в основном для психологического эффекта. Общие слова и цифры, результаты статистики вряд ли могут произвести на руководство заказчика сильное впечатление.

Организация проекта

Существуют три уровня организации проекта (для больших предприятий):

Управляющий комитет (руководитель компании и его заместители). Регулярные совещания 1-2 раза в месяц. Определяет стратегию, ресурсы, принимает основные решения.

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

313

Рабочая команда по внедрению (6-7 специалистов из разных областей). Разбивается на логические группы по подразделениям, производственным направлениям и программам. Осуществляет контроль на уровне фирмы и ее отделов. Члены команд могут работать над отдельными задачами.

Важнейшая цель организации проекта – вовлечение сотрудников компании-клиента в процесс внедрения. Это достигается через распределение ответственности. Персонал отвечает за автоматизацию своих участков.

Оптимальная структура рабочей команды:

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

Задачи: освоить в необходимом объеме инструментальные средства исполнителя (―1С‖, ―Галактика‖, Scala, R3 и др.), участвовать в доводке и разработке автоматизированной системы, служить информационным ―буфером‖ между сотрудниками клиента и консультантами исполнителя; консультанты-программисты исполнителя. Задачи: разработать, внедрить,

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

Причины:

сотрудники ОИТ так или иначе уже проводили автоматизацию своего предприятия и обладают ценным ―know-how‖, которым на уровне диалога делиться, скорее всего, не станут; действительно хорошо освоить систему сотрудники могут, принимая

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

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

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

Выработка целей

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

Как уже говорилось, расчет ROI (коэффициент эффективности инвестиций) для проектов по автоматизации вызывает значительные трудности даже в наиболее ―продвинутых‖ странах. Цели не определяются с точки зрения чисто финансовой выгоды, а связываются с появлением новых источников информации или получением качественного экономического эффекта.

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

314

Данные, как товар, не должны просто лежать где-то в компании. Их надо довести до конечных пользователей, причем желательно – пока данные свежие.

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

―Клиент готов‖

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

Одним словом, можно приступать ко второй фазе автоматизации. Она также состоит из нескольких этапов.

Технический проект

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

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

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

Начальная переподготовка

Цель начальной переподготовки – обучение персонала, который затем будет работать над внедрением системы.

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

Большое значение имеет переподготовка по обеспечению необходимой точности данных (см. ниже ―Управление данными‖).

Планирование

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

Стратегический план содержит базовые принципы, в том числе:

цели;

способ автоматизации (комплексная, кустовая и т. д.);

долгосрочную техническую политику (стандарты и т. д.);

ограничения (финансовые, временные и т. д.).

Стратегия автоматизации должна соответствовать общей стратегии бизнеса.

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

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

315

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

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

В оперативном плане определяются основные этапы автоматизации и сроки их реализации (переподготовка, внедрение новых алгоритмов управления данными, переход на новую систему и т. д.).

Управление данными

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

Приведем примеры управления данными в различных областях автоматизации. Управление производственными запасами (MRP). Входные данные:

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

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

Файл данных по материально производственным запасам. Используется для хранения информации о состоянии каждого элемента производства. Минимальная точность – 95%.

Торговля (упрощенный вариант управления запасами). Входные данные: Планируемые объемы продаж.

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

Пример. Оператор не слишком уверенно работает со справочником товаров. Не найдя нужного наименования, он добавляет новый элемент, который отличается от искомого, скажем, одним пробелом (―водка особая‖ – ―водка особая‖). После чего оформляется поступление товара на склад.

Результат: на складе числится недостача, хотя на самом деле получение отражено. Вывод? Компьютер ―напутал‖. Сотрудники перестают верить программе, и во всех последующих бедах автоматически оказывается виноват компьютер.

Если ошибка не выявлена сразу, она может привести к полному хаосу (по мере отражения новых приходов и расходов).

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

Пример. Данные о разгрузке фуры задерживаются, хотя товар на склад уже поступил. Клиент торопит. Дилемма: побыстрее обслужить клиента или ждать прихода выверенных данных. Нередко выбирается первое. Некоторые фирмы ухитряются постоянно работать с отрицательным остатком на складе. Приход товара оформляется,

316

―когда есть время‖ (отгрузка – вот настоящая работа, которую надо своевременно выполнять!).

Чтобы организовать эффективное управление данными, следует:

провести переподготовку персонала (объяснить сотрудникам, почему необходима требуемая точность данных);

создать систему персональной ответственности;

обеспечить контроль.

Это самый трудоемкий этап внедрения.

Параллельное внедрение

Новые технологии целесообразно внедрять параллельно в различных областях производственной деятельности (бухгалтерия, кадры, производство, контроль качества, САПР и т. д.).

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

Выбор системы

В России этот этап имеет свои особенности. Как правило, проект по внедрению реализует поставщик конкретного программного обеспечения, так что речь о реальном выборе не идет. Однако в последнее время увеличился спрос на услуги консалтинговых фирм, не ―привязанных‖ к конкретной системе. Их подход более объективен. Они не стремятся выполнить план продаж определенного продукта и могут сосредоточиться на исследовании бизнес-процессов и поиске средства повысить эффективность работы предприятия.

Безусловно, многое зависит от конкретных участников проекта. Помню случай, когда компания, продвигающая R3, проанализировав деятельность предприятиязаказчика (представитель автомобильной промышленности), предложила ему установить систему Baan. В то же время так называемая ―независимая консалтинговая компания‖ активно ―впаривала‖ всем подряд ПО конкретного производителя, который ей за это приплачивал.

Ввод в эксплуатацию

Есть несколько способов приступить к использованию новой системы:

Параллельная стратегия. Одновременная работа вручную, на ―старой‖ системе и на внедренной. Результаты постоянно сравниваются, новая система адаптируется. Недостаток – значительные трудозатраты (вследствие дублирования), большие сроки внедрения.

Скачок (шоковая терапия). ―С понедельника работаем на новой системе!‖ Эффективно, но иногда приводит к провалу.

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

Узкое место. Автоматизация самого ―узкого‖ производственного места с постепенным расширением области автоматизации.

Этапы развития функциональности

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

Создание прототипа (прототопирование). Под прототипом понимается набор программ, моделирующий в общих чертах работу системы. Прототип

317

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

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

Разработка и внедрение. Функциональность доведена до оптимального состояния, система готова к эксплуатации.

Оценка результатов

Получение ―обратной связи‖: результаты деятельности системы сравниваются с целями, сформулированными на начальном этапе и скорректированными в процессе внедрения. Данный этап позволяет понять, насколько успешен проект внедрения.

Анализ текущего состояния

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

Постоянная переподготовка

Переподготовка не завершается после внедрения системы. Она должна проходить регулярно.

Старый добрый ГОСТ

Сейчас нередко звучат призывы активнее обращаться к старому доброму ГОСТу, а не выдумывать какие-то новые сомнительные методики внедрения.

Несомненно, придерживаться стандартов полезно, но, на наш взгляд, существующий ГОСТ 34.601-90 (от 1992 г) не может служить эффективной методологией. Слишком сильно в нем влияние социалистической, плановой экономики. Кроме того, он чересчур универсален.

Рассмотрим содержание отечественного ГОСТа ТЗ 34.601-90 ―Автоматизированные системы стадии создания‖ (дата введения 01.01.92 г.).

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

Устанавливаются следующие стадии и этапы создания АС:

формирование требований к АС;

разработка концепции АС;

техническое задание;

эскизный проект;

технический проект;

рабочая документация;

ввод в действие;

сопровождение АС.

По аналогии с планом Уайта, первые три пункта резонно отнести к нулевому этапу проекта.

Формирование требований и разработка концепции

Формирование требований к АС включает в себя:

обследование объекта и обоснование необходимости создания АС (сбор данных об объекте автоматизации и видах деятельности, оценка техникоэкономической, социальной и др. целесообразности создания системы);

318

формирование требований пользователя к АС (характеристика объекта автоматизации, описание требований к системе).

Разработка концепции предполагает:

изучение объекта (―детальное изучение объекта автоматизации и необходимые научно-исследовательские работы, связанные с поиском путей и оценкой возможности реализации требований пользователя‖);

проведение необходимых научно-исследовательских работ; разработку вариантов концепции АС, удовлетворяющих

требованиям пользователя.

Некоторые комментарии

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

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

Втексте стандарта используется термин ―объект автоматизации‖ (―изучение объекта автоматизации‖, ―требования к объекту автоматизации‖ и т. д.). Однако под таким объектом можно понимать структуры предприятия, а можно – его бизнеспроцессы.

Взависимости от этого, участники проекта ориентируются либо на ―структурный‖ (малоэффективный), либо на ―процессорный‖ подход (что далеко не одно и то же).

Формирование требований и разработку концепции можно (с некоторой ―натяжкой‖) отнести к предпроектному обследованию. В первом случае процессы предприятия описываются ―как есть‖, во втором – ―как будет‖.

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

Ограничения затрат и эффект от системы стоит, наверное, отнести к разделам ―Технико-Экономическое Обоснование‖ (ТЭО) и ―Выработка целей‖. Определить их корректно на первом этапе все равно не удастся.

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

Как нам кажется, столь масштабные исследования можно было проводить лишь

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

Таким образом, в первых трех пунктах ГОСТа, которые мы отнесли к нулевому этапу, относительно четко описаны только две стадии: Предпроектное обследование и Техническое задание.

Следующие пункты относятся непосредственно к процессу внедрения.

Эскизный проект, технический проект, рабочая документация

Создание эскизного проекта включает:

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

319

Этот этап является фактически предварительной фазой построения технического проекта. Оно предполагает:

разработку проектных решений по системе и ее частям;

разработку документации на АС и ее части;

разработку и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) по их конструированию;

разработку заданий ―на проектирование в смежных частях проекта объекта автоматизации‖.

В рамках формирования рабочей документации предусмотрены: разработка рабочей документации на систему и ее части; разработка или адаптация программ.

Ввод в действие, сопровождение

Ввод в действие – самый емкий раздел ГОСТа. В него входят:

подготовка объекта автоматизации к вводу АС в действие;

подготовка персонала;

комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

строительно-монтажные работы;

пусконаладочные работы;

проведение предварительных испытаний;

опытная эксплуатация; проведение приемочных испытаний.

Впоследовательности, представленной в ГОСТе, можно обнаружить элементы управления данными. Предусмотрены классификация и кодирование информации (―Разработка проектных решений по системе и ее частям‖), внедрение классификаторов (―Ввод в действие‖), загрузка информации в базу данных и проверка ведения этой базы (―Пусконаладочные работы‖).

Вэтот довольно ограниченный список действий не входят: определение точности данных, контроль, общая классификация и т. д.

На подготовку персонала выделен всего один пункт, чего явно недостаточно. Этапы Опытный пример, Получение результата, Анализ текущего состояния

отражены в процессе ―Ввод в действие‖ сравнительно полно:

предварительные испытания;

опытная эксплуатация;

приемочные испытания. Сопровождение АС включает:

выполнение работ в соответствии с гарантийными обязательствами; послегарантийное обслуживание.

Выводы

Недостатки стандарта:

ГОСТ ТЗ 34.601-90 не ориентирован на конкретный вид программного продукта. В нем не учтены особенности внедрения комплексных систем автоматизации предприятия (особенно – в области обучения персонала и управления данными). Многие понятия определяются слишком широко.

ГОСТ содержит рудименты ―планово-социалистического‖ подхода к управлению предприятием. Нулевой этап внедрения плохо проработан. Отсутствует этап предварительной переподготовки. Неубедительно и непоследовательно сформулированы процессы Выработка целей и ТЭО.

320

Стандарт имеет и ряд достоинств. В частности, хорошо проработана технологическая цепочка: Обследование – Техническое задание – Технический проект и Опытный Пример – Получение результата – Анализ текущего состояния. Это универсальные элементы внедрения, необходимые для автоматизации во всех областях деятельности.

ГОСТ – открытый, публично доступный стандарт внедрения. Несмотря на все недостатки, он превосходит по качеству многие ―уникальные‖ и ―эксклюзивные‖ методики.

Знающему достаточно

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

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

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

Scala

Фирма Scala представляет свою методологию внедрения Signature. Особо подчеркивается основная идея: участники проекта действуют как единая команда.

Процесс внедрения включает шесть этапов:

анализ;

организация проекта;

настройка системы;

подготовка данных;

тестовое испытание системы;

сдача проекта.

Первые два этапа можно отнести к нулевой фазе эталонного плана проекта. ―Анализ‖ аналогичен ―Предпоектному обследованию‖ с естественным для него изучением требований бизнесс-процессов.

―Организация проекта‖ включает несколько пунктов эталонного плана. Выдержка из описания: ―…составляют план проекта, в котором определены сроки проекта, его участники и бюджет. На данном этапе создается рабочая группа проекта, которая состоит из консультантов Scala и основных пользователей системы. Также назначаются руководители проекта со стороны клиента и компании Scala. Для больших проектов создается управляющий комитет, в обязанности которого входит контроль за проведением проекта от начала до конца‖.

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

Следующие этапы относятся непосредственно к внедрению. Не приводя исходного текста методологии, ограничимся некоторыми комментариями.

Этап 3:

настройка системы; создание прототипа;