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

"Дело должно соответствовать возможностям,
действия должны соответствовать времени"
Лао-Цзы
Управление проектом построения информационной системы
Произведем небольшой экскурс в историю минувших лет. Ажиотаж вокруг бурного прогресса в области информационных технологий со многими сыграл злую шутку. До конца не понимая ценности и характеристик конечного результата, наслушавшись "убедительных" речей системных интеграторов, а, иногда, просто желая "быть на уровне", руководители большого количества предприятий начали инвестировать огромные средства в IT-проекты. Сначала фокус всеобщего интереса находился в области персональных компьютеров, потом переместился в сторону интегрированных сетей и, в конце концов, застыл на так называемых корпоративных информационных системах. Давайте, в качестве еще одной аналогии, вспомним, как изменялось всеобщее понимание о необходимости использования информационных технологий в рамках деятельности крупных предприятий. В качестве временного промежутка указан примерный период наивысшей активности компаний в реализации данного направления.

1992-94 гг. Большинству руководителей стало ясно, что за компьютерами будущее и в покупку персональных ЭВМ вкладывались довольно крупные инвестиции. Документы стали выглядеть элегантней, так как набирались в пиратских программах и распечатывались на принтерах. В определенный момент стало понятно, что поменялась только видимость работы, без какого-либо повышения эффективности бизнес-процессов. Но так как даже рынок функциональных продуктов тогда еще не достиг своей зрелости, и конкуренции практически не существовало, то сама по себе оптимизация операционного цикла предприятий не представляла собой приоритетной задачи.
1994-96 гг. Найден очевидный способ применения компьютеров: для того чтобы они смогли обслуживать бизнес-процессы (документооборот), отдельные операции которых выполняются на разных рабочих местах, нужно объединить компьютеры в единую сеть. Принимается решение о начале проекта системной интеграции. Компьютеры, которые были приобретены, к этому времени уже существенно устарели и требуют замены (модернизации). В результате проекта построена современная сеть на N рабочих мест, отвечающая всем международным стандартам. Через некоторое время, когда сглаживаются первые впечатления, приходит осознание того, что опять никаких существенных улучшений с управленческой точки зрения не произошло. Персонал приобщается к радостям Интернет (в том числе и в рабочее время), служебные записки и отчёты пересылаются в электронном виде, но в то же время, все организационные проблемы продолжают негативно сказываться на темпе развития предприятия и на общей эффективности бизнеса.
1996-2001 гг. Время активного интереса к корпоративным информационным системам. На рынке появляются программные продукты отечественных и западных разработчиков. Отечественные привлекают низкой ценой и близостью (территориальной и языковой) разработчика, а зарубежные высокой репутацией поставщика, большим опытом внедрений, огромной функциональностью и целым набором "готовых" отраслевых решений. При этом благодаря грамотно построенной рекламной политике, у многих создается иллюзорное впечатление, что они действительно могут приобрести не пакет программного обеспечения, а готовую систему управления, уже включающую в себя все необходимые правила и инструменты для ведения бизнеса.
Результатом подобных иллюзий явилось огромное количество, как проваленных проектов, так и внедренных программных продуктов которые, несмотря на то, что функционируют на рабочих местах, нисколько не решают злободневных производственных и управленческих задач. Не напоминает ли это вам упоминавшуюся ранее компьютерную сеть, которая существует только ради факта своего существования?

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

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

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

Итак, перечислим основные стадии проекта.

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

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

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

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

Управление проектом организационных изменений.
Утверждение модели команды, модели процессов и модели рисков.
Разработка и утверждение плана-графика обследования.
Управление проектом обследования. Построение и утверждение бизнес-модели "как есть". Представление и согласование полученных результатов.
Анализ бизнес-модели "как есть", разработка и утверждение бизнес-модели "как должно быть", планирование проекта реорганизации. Разработка технического задания на реорганизацию.
Управление проектом реорганизации бизнес-процессов и отдельных подсистем (например, системы мотивации) предприятия согласно техническому заданию.
Очень часто случается, что этим этапом пренебрегают и, в результате, автоматизация не даёт никаких ощутимых результатов. Внедрение ИС оправдано лишь в тех случаях, когда деятельность предприятия соответствует стратегии развития и все методы управления, лежащие в основе требований по функциональности ПК уже имеют свой утвержденный регламент. Другими словами, нет никакого смысла покупать программный модуль "Бюджетирование" и внедрять его, если сама система бюджетирования на предприятии отсутствует. То же самое можно сказать об оперативности обработки и доставки управленческой информации. Если в этом процессе возникают ситуации, когда задержки вызваны организационными проблемами, то и при наличии ИС требуемой полноты и актуальности информации добиться невозможно.

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

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

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

Утверждение новой бизнес-модели "как есть", соответствующей бизнес-процессам предприятия после осуществления реорганизации.
Конкретизация целей и критериев успешности проекта построения ИС.
Разработка функциональных и технических требований к ПК.
Выбор поставщика ПК.
Формулирование требований к ПК (функциональность, открытость, развиваемость математической модели, технические требования, безопасность, интерфейс, документация, наличие успешно реализованных проектов).
Формулирование требований к поставщику ПК (политика ценообразования, форма контракта, принципы обслуживания и поддержки, кадровые возможности, финансовая стабильность).
Утверждение требований по форме и графику предоставления информации конкурсантами.
Разработка требований к форме презентации, подготовка контрольных примеров.
Рассылка тендерной документации и организация тендера. Выбор поставщика решения или принятие решения об индивидуальной разработке.
Определение формы сотрудничества и заключение контракта на поставку ПК.
Управление проектом построения и развития ИС
Утверждение модели команды (рабочей группы проекта), модели процессов и модели рисков.
Внесение в бизнес-модель корректив, обусловленных развитием компании (если необходимо). Разработка и утверждение информационной модели.
Разработка и утверждение плана-графика работ.
Конфигурирование и развитие ИС следует осуществлять в соответствии с принципом версионности. Длительность работ по созданию одной версии не должна быть очень большой (обычно не более года). Это связано со скоростью изменения бизнес-модели (связанной с развитием компании) и с прогрессом в отрасли информационных технологий. Подход к внедрению должен быть итеративным (циклическим): когда один цикл внедрения близок к завершению, должен планироваться следующий.

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

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

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

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

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