Автор статьи: Верников Г.Г.
>
Управление проектом построения информационной системы
Произведем небольшой экскурс в историю минувших лет. Ажиотаж вокруг бурного прогресса в области информационных технологий со многими сыграл злую шутку. До конца не понимая ценности и характеристик конечного результата, наслушавшись <убедительных> речей системных интеграторов, а иногда просто желая <быть на уровне>, руководители большого количества предприятий начали инвестировать огромные средства в IT-проекты. Сначала фокус всеобщего интереса находился в области персональных компьютеров, потом переместился в сторону интегрированных сетей и, в конце концов, застыл на так называемых корпоративных информационных системах. Давайте, в качестве еще одной аналогии вспомним, как изменялось всеобщее понимание о необходимости использования информационных технологий в рамках деятельности крупных предприятий. В качестве временного промежутка указан примерный период наивысшей активности компаний в реализации данного направления.
- 1992-1994 гг. большинству руководителей стало ясно, что за компьютерами будущее и в покупку персональных ЭВМ вкладывались довольно крупные инвестиции. Документы стали выглядеть элегантней, так как набирались в пиратских программах и распечатывались на принтерах. В определенный момент стало понятно, что поменялась только видимость работы, без какого-либо повышения эффективности бизнес-процессов. Но так как даже рынок функциональных продуктов тогда еще не достиг своей зрелости и конкуренции практически не существовало, то сама по себе оптимизация операционного цикла предприятий не представляла собой приоритетной задачи.
- 1994-1996 гг. Найден очевидный способ применения компьютеров: для того чтобы они смогли обслуживать бизнес-процессы (документооборот), отдельные операции которых выполняются на разных рабочих местах, нужно объединить компьютеры в единую сеть. Принимается решение о начале проекта системной интеграции. Компьютеры, которые были приобретены, к этому времени уже существенно устарели и требуют замены (модернизации). В результате проекта построена современная сеть на N рабочих мест, отвечающая всем международным стандартам. Через некоторое время, когда сглаживаются первые впечатления, приходит осознание того, что опять никаких существенных улучшений с управленческой точки зрения не произошло. Персонал приобщается к радостям интернета (в том числе и в рабочее время), служебные записки и отчеты пересылаются в электронном виде, но в то же время все организационные проблемы продолжают негативно сказываться на темпе развития предприятия и на общей эффективности бизнеса.
- 1996-2001 гг. Время активного интереса к корпоративным информационным системам. На рынке появляются программные продукты отечественных и западных разработчиков. Отечественные привлекают низкой ценой и близостью (территориальной и языковой) разработчика, а зарубежные высокой репутацией поставщика, большим опытом внедрений, огромной функциональностью и целым набором <готовых> отраслевых решений. При этом благодаря грамотно построенной рекламной политике у многих создается иллюзорное впечатление, что они действительно могут приобрести не пакет программного обеспечения, а готовую систему управления, уже включающую в себя все необходимые правила и инструменты для ведения бизнеса. Результатом подобных иллюзий явилось огромное количество как проваленных проектов, так и внедренных программных продуктов, которые, несмотря на то, что функционируют на рабочих местах, нисколько не решают злободневных производственных и управленческих задач. Не напоминает ли это вам упоминавшуюся ранее компьютерную сеть, которая существует только ради факта своего существования? Определение информационной системы приводилось в первом разделе, и, исходя из него, очевидна разница между понятиями <управленческий программный комплекс> и <управленческая информационная система>.
- Что будет следующим шагом? Скорее всего, в ближайшем будущем обретут гладкую маркетинговую форму и будут выдвинуты предложения и о поставке комплексного продукта, включающего в себя как управленческие технологии, так и информационный инструментарий для их поддержки. Однако в любом случае подобные решения нельзя оценивать в отрыве от конкретного предприятия, стратегии его развития и существующей системы менеджмента.
В подавляющем большинстве случаев проекты построения информационных систем традиционно начинаются с выбора программного комплекса. При этом, как правило, выбор происходит не на основе анализа соответствия решения требованиям заказчика, а исходя из оценки программного продукта самого по себе, что в дальнейшем способно повлечь за собой существенные проблемы.
Далее, в виде иерархической последовательности перечислены основные этапы проекта построения ИС. Стоит отметить, что рассматривается самый общий случай, когда управляющая (внедряющая) компания отличается от компании — поставщика ПК, как это принято на Западе при реализации крупных проектов. Такой подход имеет множество рациональных обоснований. Дело в том, что когда управляющая компания является одновременно и поставщиком программного решения, обычно она не может в полном объеме представлять интересы заказчика в проекте, так как вынуждена в той или иной степени отстаивать <интересы> программного продукта. Подобная ситуация аналогична той, когда обоснование применимости или тестирование программного модуля поручают написавшему его программисту. С другой стороны, проект внедрения ИС никогда не должен носить софтверный оттенок, так как основной его целью является оптимизация управленческой инфраструктуры. Поэтому проектным управлением должны заниматься не специалисты по конфигурированию ПК, а профессиональные бизнес-консультанты.
итак, перечислим основные стадии проекта.
- Определение целей проекта.
- Осуществление процедуры бенчмаркинга: анализ опыта других предприятий (обычно близких по профилю, отрасли, рынку, методам ведения бизнеса и т.д.), связанного с внедрением ИС.
- Определение целей проекта в контексте повышения эффективности решения существующих управленческих задач и возможности внедрения принципиально новых управленческих технологий.
- Определение укрупненных показателей эффективности бизнес-процессов, подлежащих автоматизации (целевых бизнес-процессов), и формирование первоначальных критериев успешности проекта.
- Определение приемлемого финансового плана-графика проекта.
- Обследование предприятия и подготовка к проекту внедрения.
- Организация тендера и выбор управляющей (внедряющей) компании.
Выбор управляющей компании обычно играет решающую роль с точки зрения общей результативности проекта. Самые серьезные риски чаще всего обусловлены некачественным проектным менеджментом, поэтому ошибка в выборе управляющей компании может грозить серьезными неудачами. При анализе претендентов следует руководствоваться следующими главными факторами: наличие формализованной (отчуждаемой) методологии проектного управления, высокая деловая репутация компании, присутствие квалифицированных консультантов и бизнес-аналитиков, позитивный опыт работы в аналогичных проектах.
- Подготовка персонала компании к проекту изменений, разработка новой политики мотивации труда.
Почти во всех случаях проведения серьезных преобразований на предприятии возникает противодействие (как активное, так и пассивное) сотрудников на разных уровнях организационной иерархии. Это обусловлено характерной человеческой особенностью, выражающейся в опасениях по отношению к любым нововведениям, боязни утратить свою незаменимость, неготовности принимать решения и т.д. Как показывает практика, существенно уменьшить сопротивление персонала, а во многих случаях даже вызвать его заинтересованность в отношении проекта позволяет тщательная проработка новой политики мотивации труда. Другими факторами, эффективно сказывающимися на преодолении этой проблемы, являются: создание у сотрудников твердого убеждения неизбежности нововведений, поддержание высокого статуса проекта и закрепление всех проектных распоряжений соответствующими приказами руководства.
- Утверждение проектной методологии.
Обследование и реорганизация (в том случае, если они проводятся) предприятия являются первым этапом проекта внедрения, и их результаты определяющим образом влияют как на дальнейшую конфигурацию ИС, так и на соответствие результатов ожиданиям заказчика. Поэтому уже на этом этапе всегда необходимо утверждать единую концепцию управления проектом и строго следовать ей на всех последующих стадиях, при необходимости внося в регламент коррективы, обусловленные новой предметной областью.
Как правило, любая проектная методология базируется на трех обязательных понятиях: модель команды, модель процессов и модель рисков. Модель команды определяет ролевой состав рабочей группы, правила взаимодействия между ролями и ответственность за выполнение проектных задач. Модель процессов описывает регламент выполнения работ, отчетную политику и правила предоставления результатов на протяжении всего жизненного цикла проекта. Модель рисков описывает правила выявления и отслеживания статусов рисков, а также принципы поиска решений по их устранению или плановому снижению последствий от их актуализации.
- Управление проектом организационных изменений.
- Утверждение модели команды, модели процессов и модели рисков.
- Разработка и утверждение плана-графика обследования.
- Управление проектом обследования. Построение и утверждение бизнес-модели <как есть>. Представление и согласование полученных результатов.
- Анализ бизнес-модели <как есть>, разработка и утверждение бизнес-модели <как должно быть>, планирование проекта реорганизации. Разработка технического задания на реорганизацию.
- Управление проектом реорганизации бизнес-процессов и отдельных подсистем (например, системы мотивации) предприятия согласно техническому заданию.
Очень часто случается, что этим этапом пренебрегают, и в результате автоматизация не дает никаких ощутимых результатов. Внедрение ИС оправдано лишь в тех случаях, когда деятельность предприятия соответствует стратегии развития и все методы управления, лежащие в основе требований по функциональности ПК, уже имеют свой утвержденный регламент. Другими словами, нет никакого смысла покупать программный модуль <Бюджетирование> и внедрять его, если сама система бюджетирования на предприятии отсутствует. То же самое можно сказать об оперативности обработки и доставки управленческой информации. Если в этом процессе возникают ситуации, когда задержки вызваны организационными проблемами, то и при наличии ИС требуемой полноты и актуальности информации добиться невозможно.
Никогда не следует забывать о том, что если мы планируем внедрять ИС класса MRPII, то для начала нужно определиться с тем, как мы будем разрабатывать политику планирования производства с учетом новых условий, и уже потом разрабатывать техническое задание по конфигурации программного комплекса.
На самом деле, даже в тех случаях, когда поставщики ПК утверждают, что внедрение возможно по принципу <как есть>, они лукавят, так как всегда наличие ИС подразумевает новые методы работы с информацией, а соответственно и новую бизнес-модель предприятия. Только в этом случае изменения будут продиктованы конфигурацией ПК, а не реальными показателями эффективности бизнес-процессов.
Реорганизация бизнес-процессов является отдельной и очень обширной темой, актуальность которой отразилась в создании целых научных школ, поэтому в контексте этой статьи мы не будем детально рассматривать разнообразие подходов к организационному проектированию.
- Утверждение новой бизнес-модели <как есть>, соответствующей бизнес-процессам предприятия после осуществления реорганизации.
- Конкретизация целей и критериев успешности проекта построения ИС.
- Разработка функциональных и технических требований к ПК.
- Выбор поставщика ПК.
- Формулирование требований к ПК (функциональность, открытость, развиваемость математической модели, технические требования, безопасность, интерфейс, документация, наличие успешно реализованных проектов).
- Формулирование требований к поставщику ПК (политика ценообразования, форма контракта, принципы обслуживания и поддержки, кадровые возможности, финансовая стабильность).
- Утверждение требований по форме и графику предоставления информации конкурсантами.
- Разработка требований к форме презентации, подготовка контрольных примеров.
- Рассылка тендерной документации и организация тендера. Выбор поставщика решения или принятие решения об индивидуальной разработке.
- Определение формы сотрудничества и заключение контракта на поставку ПК.
- Управление проектом построения и развития ИС.
- Утверждение модели команды (рабочей группы проекта), модели процессов и модели рисков.
- Внесение в бизнес-модель коррективов, обусловленных развитием компании (если необходимо). Разработка и утверждение информационной модели.
- Разработка и утверждение плана-графика работ.
Конфигурирование и развитие ИС следует осуществлять в соответствии с принципом версионности. Длительность работ по созданию одной версии не должна быть очень большой (обычно не более года). Это связано со скоростью изменения бизнес-модели (связанной с развитием компании) и с прогрессом в отрасли информационных технологий. Подход к внедрению должен быть итеративным (циклическим): когда один цикл внедрения близок к завершению, должен планироваться следующий.
- Управление конфигурацией ПК согласно требованиям бизнес-модели.
Процедуры управления конфигурацией обычно описываются в плане либо в нем указывается ссылка на отдельный документ, который рассматривается как стандарт управления конфигурацией.
- Управление тестированием (стабилизацией).
Обычно тестирование бывает двух категорий: функциональное и пользовательское. Целью функционального тестирования является максимально полная проверка каждого программного модуля на предмет сбоев. Для этой категории разрабатываются специальные типы тестов. Пользовательское тестирование — это следующий уровень тестирования, который выполняется, когда формальные контрольные примеры уже практически не выявляют ошибок. В этом случае продукт тестируется путем имитации действий различных групп пользователей.
- Управление рисками и качеством внедрения.
Риск всегда является неотъемлемой составляющей любого сложного и ответственного процесса. Более того, совершение рискованных действий необходимо для прогресса, а ошибки, как известно, являются основой приобретения опыта. Несмотря на то, что некоторые риски неизбежны, это не означает, что попытки определить их и управлять ими вредят творческой работе. Более подробно мы остановимся на процедуре управления рисками в следующей статье, а сейчас лишь отметим, что процедурное управление рисками на всем протяжении проекта является одним из самых главных факторов успеха.
Обеспечение качества готового продукта (версии) достигается нахождением оптимального баланса между тремя составляющими: функциональность, надежность, дата выпуска. Каждая из этих составляющих формируется на основе ожиданий заказчика. Очевидно, что не каждый проект является критичным к дате выпуска, так же как не каждый проект критичен к полноте реализации функциональности. Некоторые ошибки можно легко обойти путем изменения сценария действий пользователя, так как часто сохранение запланированного срока ввода продукта в эксплуатацию оказывается важнее, чем задержка из-за исправления ошибок и выполнения повторного тестирования.
- Запуск ИС (версии) в опытную эксплуатацию.
- Разработка правил работы с ИС и утверждение процедуры внесения изменений в конфигурацию.
- Обучение и сертификация пользователей и администраторов.
- Организация работы подразделения технической и пользовательской поддержки.
Отметим дополнительно, что процесс управления проектом развития ИС является бесконечным: его динамика определяется темпом изменения всех составляющих системы, и в первую очередь развитием бизнеса предприятия.
Опубликовано в номере: Менеджмент в России и за рубежом №2 / 2003
