Лекция
№5
Планирование
проекта ИС
Оглавление
1. Обследование объекта информатизации
2. Технико-экономическое
обоснование
3. Оценка
целесообразности проекта (TELOS)
Обследование
проводится в обязательном порядке на самом первом этапе для сбора информации о
целях и задачах компании в целом и внедряемой системы в частности, а также
получению данных об основных бизнеспроцессах
и покрывающем их ландшафте информационных систем
(для определения в нем места внедряемого решения).
Важно
верно определить:
‒ Организационный объем проекта
(затрагиваемые реализацией проекта подразделения).
‒ Наличие зависимостей от других
проектов.
ПРИМЕР Если в этот же период внедряются другие системы и в обоих
проектах задействованы одни и те же специалисты ИТ-департамента,
одно оборудование, если они оба требуют незапланированных в исходном бюджете
дополнительных расходов.
‒ Планируемые финансовые, инфраструктурные
и человеческие ресурсы, бюджет проекта (включая необходимые
закупки – например, лицензии от поставщика ПО – и планируемые затраты при
необходимости оплаты услуг подрядчика по сопровождению, по обслуживанию
серверов и т.д.).
Принято различать две категории обследования:
‒ Экспресс-обследование, имеющее своим результатом:
·
Краткое
описание текущей бизнес-модели
предприятия;
·
Коммерческое
предложение со сформулированными проблемами, а также ориентировочными сроками и
бюджетом работ по дальнейшему информационному обследованию и непосредственно
внедрению системы.
‒ Информационное обследование, по
результатам проведения которого должны быть подготовлены:
·
Полное
описание текущей бизнес-модели
предприятия заказчика;
·
Утвержденный
план работ по разработке и внедрению (включая состав группы внедрения с обеих
сторон).
Также по результатам
информационного обследования со стороны заказчика должны быть приняты все
организационные меры для обеспечения реализации проекта. В
частности, это относится к внутренним приказам и документам предприятия
заказчика (для назначения ответственных за предоставление информации и
взаимодействие с проектной командой в рамках внедрения).
Основными целями экспресс-обследования
являются:
‒ Выявление
основных проблем и «узких мест» по участкам бизнеспроцессов.
1.
‒ Изучение и укрупненное
описание бизнес-процессов в привязке к подразделениям предприятия с
распределением ответственности между ними.
2.
‒ Изучение и описание базы
нормативно-справочной документации, используемых на
предприятии.
3.
‒ Изучение пожеланий по
совершенствованию системы управления предприятием – и в свою очередь,
формирование предложений по решению проблем, стоящих перед предприятием.
4.
‒ Подготовка предложений по
срокам и стоимости проведения полномасштабного информационного обследования
требуемых бизнеспроцессов предприятия.
Таким образом, экспресс-обследование – это своеобразное
знакомство потенциального заказчика и исполнителя с работой друг друга, так как
первый получает взгляд на свой бизнес со стороны и точную оценку объема и
ресурсных требований к возможному проекту, а исполнитель – важную информацию
для дальнейшего использования при подготовке коммерческого предложения и реализации
проекта.
В качестве предусловий со стороны заказчика для старта этапа
требуется подготовить и обеспечить издание приказа по предприятию о проведении экспресс-обследования существующей
системы управления, а также создать / утвердить приказом по предприятию рабочую
группу со стороны заказчика. Первоначально
в нее могут входить следующие лица:
‒ Куратор проекта
(представитель высшего руководства, иногда называемый спонсором проекта, т.е.
отвечающим за финансирование проекта).
‒ Руководитель проекта (менеджер,
ответственный за принятие решений в рамках согласованных в договоре бюджета и
сроков).
‒ Руководитель
финансового подразделения.
‒ Главный бухгалтер.
‒ Руководитель планового подразделения.
‒ Руководитель производственного
подразделения.
‒ Руководитель сбытового
(маркетингового) подразделения.
‒ Руководитель снабженческого
подразделения.
На этом этапе, как
правило, впервые происходит встреча бизнес-заказчика и спонсора проекта с
проектной командой для обсуждения постановки задачи и основных требований и
ограничений (чаще высокоуровневых). Для сбора дополнительной / более детальной и оперативной информации применяются
заранее разработанные специалистами команды исполнителя анкеты, заполняемые
рабочей группой / ключевыми специалистами по функциональному признаку в течение
одной недели. Анкета экспресс-обследования предназначена для предварительного знакомства с предприятием,
определения проблематики и потребностей развития компании. Она выдается
руководителю проекта; возможно заполнение отдельных разделов анкеты
руководителями подразделений, но в любом случае заполненная анкета должна быть
заверена куратором проекта. По результатам анализа анкеты
возможно определить потенциальный круг задач и варианты совместной работы
заказчика и исполнителя для их решения.
Среди информации, предоставляемой в анкете такого рода:
·
‒
Информация о предприятии.
·
‒
Система управления предприятием:
·
Организационная
структура.
·
Процессы
управления.
·
Информационное
обеспечение процессов управления.
·
Документооборот.
·
Бизнес-процессы
основной деятельности.
·
Автоматизация.
·
…
‒ Актуальные вопросы развития.
·
‒
Дополнительные пожелания заказчика, примечания.
·
‒
Данные о сотруднике, ответственном за заполнение анкеты.
В результате основного анкетирования какие-то моменты могут
быть до конца не выяснены, где-то могут возникнуть противоречия. Поэтому
возможно осуществление обратной связи по анкетам с целью уточнения ранее
полученных данных. При этом крайне важное значение
имеет то, что консультантам должны предоставляться исключительно точные данные
в пределах предварительно оговоренных руководством предприятия информационных
границ. Продолжительность обратной связи по анкетам – 3-7 дней. Основным
результатом проведения экспресс-обследования
является отчет, формируемый консультантами в течение 1-2 рабочих недель. В итоге отчет о результатах проведенного экспресс-обследования
будет описывать следующие направления:
1.
Краткая характеристика объекта
исследования. Основные виды деятельности.
2.
Схема и краткое описание
организационной структуры предприятия. Основные функции обследуемых структурных
подразделений с группировкой по бизнес-процессам.
3.
Краткое описание существующих на
предприятии бизнес-процессов, принципов взаимодействия между подразделениями
предприятия заказчика.
4.
Описание информационного
взаимодействия подразделениями.
5.
Описание основных проблем и слабых
мест на обследуемых участках бизнес-процессов.
6.
Пожелания заказчика по
совершенствованию системы управления предприятием.
7.
Предложения о дальнейшем
сотрудничестве, рекомендации по решению выявленных проблем и ориентировочная
стоимость работ.
В результате экспресс-обследования
консультанты получают знания о предприятии заказчика, включая представление о его бизнес-модели.
В свою очередь, заказчик вместе с отчетом получает краткое описание бизнес-модели с ценной информацией
о выявленных возможностях для улучшения – и конечно, коммерческое предложение с
указанием ориентировочных сроков и стоимости работ по полному информационному
обследованию и проведению работ по созданию и внедрению информационной системы
на предприятии
ТЭО,
технико-экономическое обоснование (в английской терминологии business case) – экономическое, бизнес-ориентированное обосновании
выгод от ИТ-инвестиций (например, в информационную
систему) и прогнозировании объема этих выгод.
Ключевая
проблема, с которой сталкиваются как «обосновывающие»
систему, так и принимающие решение – невозможность
объективно предсказать и рассчитать совокупный эффект от самой системы и от ее
взаимодействия с другими программными решениями, входящими в архитектуру
предприятия. Именно поэтому ТЭО чаще
всего превращается в декларативный документ, содержащий цели и задачи внедрения
системы, ожидаемые результаты и возможные риски, по сути
представляя собой краткую «бизнес-версию» технического задания. Содержание ТЭО
в разных компаниях различается, однако в классическом случае оно может состоять из следующих разделов:
1.
Резюме для руководства. Основные показатели эффективности проекта. ПРИМЕР ‒ Чистый денежный поток (млн.
руб.). ‒ Суммарный денежный поток (млн. руб.). ‒ NPV, чистая
приведенная стоимость (млн. руб.). ‒ IRR, внутренняя норма доходности, %.
‒ Срок окупаемости, лет.
2. Описание проекта.
2.1
Предпосылки реализации проекта. Документы, нормативно-правовые акты, события.
2.2.
Мировой и отраслевой опыт реализации подобных проектов. Аналогичные проекты,
выполненные в схожих предметных областях / индустриях, их достижения и ошибки.
2.3.
Ключевые заинтересованные стороны. Заказчики проекта: функциональные
подразделения различных уровней иерархии и конкретные сотрудники (в т.ч.
акционеры и топ-менеджмент), в чьих интересах / с учетом
чьих потребностей планируется реализация проекта
2.4.
Организационный масштаб проекта. Охватываемые проектом подразделения /
сотрудники.
2.5.
Проектные зависимости. Другие проекты, результаты которых используются при
реализации данного проекта. И напротив, проекты, реализация которых возможна
только после окончания текущего.
2.6.
Основные области достигаемых бизнес-выгод.
ПРИМЕР
‒ Сокращение
рисков несоблюдения установленных сроков и объемов продукции.
‒ Исключение рисков несоответствия
местных нормативов требованиям корпоративных и отраслевых регламентирующих
актов.
‒ Повышение
качества производимой продукции.
‒ Сокращение
расходов на создание, развитие и сопровождение ИТ
инфраструктуры.
‒ Обеспечение качества и достоверности
информации.
3. Оценка коммерческой целесообразности
реализации проекта.
3.1. Затраты и экономика проекта. Покупка
аппаратного и программного обеспечения, оплата услуг подрядчиков, операционные
расходы, обслуживание оборудования и прочие статьи затрат.
3.2.
Основные области выгод. Экономические выгоды. Оценка чистого денежного потока,
внутренней нормы доходности, срока окупаемости.
3.3.
Структура финансирования проекта. Определение источников финансирования
(внешние инвесторы, бюджет подразделения, …).
4.
Матрица основных проектных рисков. Ключевые ассоциированные с проектом риски,
сгруппированные по категориям (например, вероятность реализации риска и размер
возможных убытков).
Перед
тем, как приступать к разработке, важно еще раз
убедиться, что проведенные работы по анализу, обоснованию и проектированию системы достаточны для перехода к
следующему этапу. Напоминая по своей сути SWOT и PEST-анализы, акроним TELOS содержит основные аспекты, при
рассмотрении которых можно удостовериться, что проект по реализации системы
реалистичен и имеет значительный потенциал.
‒ Tехнические (Technological).
Проверка наличия инфраструктурных ресурсов организации, а также
квалифицированного персонала и проектного опыта для создания и поддержки
системы. Описание потенциальных сложностей и возможностей их разрешения.
‒ Экономические
(Economical). Определение ожидаемых экономических
выгод от реализации информационной системы.
ПРИМЕР Снижение времени обработки транзакции на 18 %.
‒ Юридические (Legal).
Определение, насколько все технологические спецификации и существующая
функциональность обеспечивают требования к безопасности данных и их
предоставлению в случае необходимости.
ПРИМЕР Любые системы
обработки персональных данных должны обеспечивать минимальный (закрепленный
регламентами и законодательством) уровень защиты информации.
‒ Операционные
(Operatoinal). Покрытие сформированных на этапе
анализа требований заинтересованных сторон подготовленным проектом.
Определение, насколько система удовлетворяет возможностям и потребностям
бизнеса с точки зрения сроков проекта, встраивания в бизнес-процессы в текущих
рыночных условиях в моменту
создания системы. Рассмотрение критериев надежности, возможности поддержки,
удобства интерфейса, продуктивности, стабильности и прочих факторов создания
системы.
‒
Сроки реализации (Scheduling).
Оценка сроков создания системы для определения возможных изменений во внешней
среде за время реализации проекта. Оценка, насколько реалистичны поставленные
крайние сроки сдачи системы в эксплуатацию, а также промежуточные вехи.
Собрав требования и
подходя к этапу проектирования, проектной команде предстоит принимать решение о
том, каким образом подойти к выбору программного решения: необходимо ли его
разрабатывать с нуля, либо приобрести уже существующий на рынке и
зарекомендовавший себя продукт. Заказные
КИС являются уникальными, создаются исключительно для нужд и достижения бизнес-целей конкретной компании
(чаще всего, конкретной узкой специализации или для автоматизации одной
функции). Как следует из названия, такие системы не имеют аналогов и не
подлежат дальнейшему тиражированию (а часто – и масштабированию). Обычно ИС
такого класса не имеют прототипов. Иногда использование прототипов возможно,
однако потребуется внесение серьезных изменений качественного характера.
Отдельно необходимо отметить, что к системам данного типа будем относить как
самостоятельную разработку внутренними ИТ-подразделениями
компании, так и действительно заказную разработку, осуществляемую силами
подрядчиков / внешних компаний.
Среди основных причин, по которым компании
рассматривают разработку
бизнес-приложений с нуля как подходящий для себя вариант:
1. «Не существует двух одинаковых компаний, а значит, стандартные
решения не смогут целиком отразить специфику компании».
2.
«Стандартные системы содержат избыточный набор функций, за которые приходится
платить».
3.
«Стоимость самостоятельной разработки ниже стоимости лицензий и услуг по
системной интеграции / консалтингу.
Разработках
таких КИС сопряжена с дополнительными рисками в
получении необходимых результатов. В случае
самостоятельной разработки важно помнить о том, что компетенции для работы с подобными системами (и / или их создания)
часто являются уникальными, а значит риск
ухода ключевых сотрудников, работавших с ними тоже нужно принимать во
внимание. Также у разрабатываемых «для
себя» приложений часто обнаруживаются ошибки, вызванные недостаточно
тщательно проведенным тестированием. В силу того, что в большинстве компаний в штате ИТ-специалистов
нет отдельных ответственных за версионность,
бета-тестирование и другие аспекты процесса внедрения, основная часть
разработчиков фокусируется исключительно на реализации функциональных
возможностей и производительности системы, не уделяя должного внимания
«чистоте» и безопасности кода.
В
случае заказной разработки часто встречаются случаи неверного толкования технического задания (или
ошибок при его составлении), высокая
оценка стоимости реализации проекта, коммуникационные проблемы, неполное
документирование системы.
По всем вышеописанным
причинам, а в первую очередь, в силу развитости современной индустрии решений
для автоматизации деятельности компании на сегодняшний момент заказная
разработка уже далеко не столь распространена, как 15 лет назад. Ранее
популярность подобных решений объяснялось тем, что адаптируемых или
«коробочных» КИС для отраслей / бизнесов определенного масштаба почти не
существовало. Сейчас почти любой проект разработки / внедрения предполагает
лишь доработку стандартной или отраслевой конфигурации под согласованные с
заказчиков требования. Указанный процесс и будет рассматриваться далее.
Противоположной категорией являются тиражируемые КИС.
Иногда их еще называют «коробочными» или «шаблонными» решениями, что однако не совсем корректно в силу адаптации подобных
систем к нуждам конкретного предприятия. Как правило, в основу подобных систем заложены общие процессы и свойства предприятий
(примерно одного размера и работающих в одной индустрии). Производитель ИС такого типа при разработке использует опыт собственных
проектов и «лучшие практики» (best practices) отрасли. Соответственно, одним из критериев
при выборе ИС становится репутация и
опыт производителя системы, а также общий
масштаб системы и ее соответствие специфике предприятия, несмотря на то что способность к адаптации так или иначе предусмотрена в
большинстве информационных систем. Процесс
адаптации тиражируемых КИС может быть как одноуровневым, так и двухуровневым.
1.
В первом случае настройку и изменение параметров исходной системы, купленной у
предприятия-производителя, проводит непосредственно проектная команда по
внедрению – либо со стороны исполнителя (консалтинговых компаний и системных
интеграторов), либо собственными силами ИТ-подразделения
компании.
ПРИМЕР Закупка пакета лицензий SAP Business One с услугами по
интеграции непосредственно у российского офиса SAP AG.
2.
Во втором случае (особенно в случае зарубежных КИС) в исходное решение
российскими компаниями–системными интеграторами на
основе собственного опыта в национальной отраслевой специфике с учетом
особенностей российского законодательства вносятся модификации и ими же
производится дистрибуция созданного отраслевого решения (вместе с услугами по
интеграции).
ПРИМЕР Партнерство NaviCon Group и Microsoft, в рамках которого на базе решения Mictosoft Dynamics NAV разработан
локализированный продукт NaviCon Trade,
автоматизирующий управление сбытом, заказами и взаиморасчетами с клиентами в
торговых предприятиях.
Резюмируя сказанное,
самостоятельная (заказная) разработка предполагает равномерное распределение
внимания между всеми фазами жизненного цикла (при написании кода с нуля), в то
время как доработки и настройка тиражируемых информационных систем концентрируются
на сборе требований, сравнении их с имеющимся решением и последующем
развертывании ИС. Далее в пособие жизненный цикл информационных систем будет
рассматриваться в контексте именно этого подхода в силу его распространенности
и оптимальности в современных условиях жесткой конкуренции и стремления к
сокращению времени и бюджета внедрения.