Стратегия развития информационных систем

Стратегия внедрения информационных систем

Систематизация проектов и оси координат

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

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

Стратегия развития: куда движется компания

Любое развитие информационной системы направлено на улучшение процессов управления и деятельности организации. Для описания всех возможных ситуаций можно ввести две оси:
1. Изменение управления — текущий уровень управления и планируемый целевой уровень, на который мы хотим перейти.
2. Средства реализации — каким способом создаётся система. Два полюса: заказная разработка (собственная, уникальная система) и типовое проектное решение (промышленная система, тиражируемый продукт). Фактически это каноническое и типовое проектирование, изученные ранее.

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

Траектории перехода от собственных решений

• Развитие собственной системы без смены типа средства. Переход на новый уровень управления остаётся в рамках заказной разработки. Требуется управление группой своих разработчиков (вероятно, внутреннее подразделение) и планирование развития по спиральной модели жизненного цикла. Мы остаёмся в сложившихся условиях и должны эффективно работать в них.
• Переход от собственного решения к типовому при хорошо описанных бизнес-процессах. Если компания чётко понимает свои процессы и способы их автоматизации, она может частично доработать имеющиеся средства, а затем уйти на типовое решение и наращивать его функциональность. Альтернативная траектория: в молодой растущей компании, где понимание рациональной автоматизации ещё не сформировалось, приходится экспериментировать с собственными разработками, уточнять требования и только затем сформулировать чёткие запросы к промышленной системе – какие модули нужны и как их настраивать.
• Переход к типовому решению без существенного улучшения управления. Такой вариант встречается, когда внедрение служит целям повышения капитализации, имиджа или маркетинга. Деятельность компании меняется мало, но наличие известной системы (например, SAP R/3) демонстрирует зрелость и позволяет выгодно продать бизнес. Риски и эффект лежат в иной плоскости.
• Замена типового решения на собственную разработку. Возникает, когда особенности бизнеса не поддерживаются ни одной существующей системой в полном объёме. Дорабатывать промышленные продукты оказывается нерационально, и компания создаёт уникальное решение. Пример: бизнес по продаже лицензируемого медиаконтента с нетиповыми правовыми процедурами.

Условия выбора стратегии развития

Прежде чем принимать решение о траектории, необходимо оценить готовность компании. Если условия не выполнены, выводы будут некорректными и приведут к тупику. Обязательные условия:
• Наличие стратегии бизнеса. Нужно понимать, куда движется бизнес минимум на 3–4 года. Проект внедрения длится 1–2 года, и система должна отработать без существенных модификаций ещё несколько лет, чтобы обеспечить отдачу.
• Поддержка руководства и коллектива. Проект, реализуемый во враждебной среде, обречён на провал. Человеческий фактор критичен.
• Задокументированные бизнес-процессы. Они не обязательно должны быть оптимизированы до внедрения (некоторые методологии откладывают оптимизацию на поздние этапы), но они должны быть зафиксированы. Невозможно автоматизировать то, что не описано.
• Инфраструктура, способная поддержать предполагаемые решения.

Стратегии внедрения: как организовать проект

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

Базовые понятия эффективности и риска

• Эффективность внедрения здесь понимается качественно: это соответствие системы функциональным требованиям бизнеса и оптимизация затрат на исполнение бизнес-функций. Строгого количественного определения на данном этапе не вводится.
• Риски — спекулятивные характеристики, которые могут повлиять как негативно, так и позитивно (вероятность событий и их последствия).

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

Основные стратегические блоки

1. Внедрение силами внешнего партнёра или своими силами

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

2. Оптимизация бизнес-процессов перед внедрением или в его процессе

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

3. Адаптация системы под бизнес-процессы или изменение процессов под логику системы

• Адаптация системы (глубокие доработки). На этапе внедрения риск не слишком высок, поскольку деятельность компании не перекраивается. Основные риски переносятся на этап эксплуатации: требуются уникальные специалисты, знакомые с конкретными доработками, любое развитие системы усложняется, а вмешательство в архитектуру обычно снижает надёжность и производительность. Эффективность зависит от качества существующих бизнес-процессов.
• Изменение бизнес-процессов под логику системы. Снижает совокупную стоимость владения. Система остаётся стандартной, её могут сопровождать специалисты по стандартному функционалу, модификации проходят штатно. На этапе внедрения эффективность может быть разной: если система хорошо подходит к бизнесу, изменения минимальны и эффективность высока; если подходит плохо, вынужденные изменения могут быть нерациональными. Такой стратегии придерживается, в частности, SAP, предлагая ориентироваться на «лучшие мировые практики» (best practices), заложенные в продукт.

4. Выделенный проект или внедрение в рамках текущих проектов

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

5. Полнофункциональное (большой скачок) или поэтапное внедрение по модулям

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

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

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

Оценка эффективности проектов внедрения

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

Два основных подхода

1. Позиционирование эффекта (распределение эффекта). Для каждой операции оценивается показатель TPI (Transaction Performance Indicator) – характеристики затрат ресурсов, времени, финансов и др. Далее анализируется, как внедрение информационной системы изменяет эти показатели. В результате получается не единая цифра, а описание конкретных благ от автоматизации. Работа механически сложная, но не требует глубокой теории.
2. Общая стоимостная оценка проекта. Используются известные финансовые показатели.

Основные финансовые показатели

• Чистая приведённая стоимость (Net Present Value, NPV). Характеризует прибыльность проекта и позволяет сравнивать проекты. Ответ даётся лишь в терминах «прибылен/неприбылен». Для CIO или менеджера проекта часто достаточно заключения о безубыточности. Ключевые нюансы:
o Распределение денежных потоков во времени кардинально влияет на NPV. При одинаковых суммах разная временная структура может дать как положительное, так и отрицательное значение.
o Ставка дисконтирования требует корректного выбора. Она не сводится к среднерыночной доходности. Корректная ставка включает компоненты, отражающие особенности компании:
• Безрисковая ставка дохода (Rf).Каждая компания определяет её по-своему. Осторожная компания может взять ставку по государственным ценным бумагам, другая – более высокую ставку, соответствующую приемлемому для неё уровню риска.
• Рыночная премия за риск и коэффициент бета (β). Коэффициент эластичности показывает, как активы компании реагируют на общерыночные изменения. Если акции компании растут при падающем рынке, это должно быть отражено в ставке дисконтирования.
Таким образом, сравнивая проекты разных компаний, необходимо учитывать, как именно считалась ставка дисконтирования у каждой из них.
• Внутренняя норма доходности (Internal Rate of Return, IRR). Показывает доходность вложений в проект. Если IRR превышает стандартную доходность (например, 10-15%), проект считается неплохим.
• Период окупаемости инвестиций. Основной запрос заказчика, но на ранних этапах планирования погрешности оценок сроков и стоимости столь велики, что вычисленный период будет весьма приблизительным. Для получения более точных данных применяются технологии мониторинга ключевых показателей деятельности после внедрения.

Неопределённость и мониторинг эффекта

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

Мониторинг деятельности в ходе внедрения даёт более объективную картину. Выделяются ключевые производственные точки, для каждой фиксируются текущие показатели (что сделано, в каком количестве). Фактически строится система TPI, позволяющая отследить, что и как изменилось после внедрения.

Экономическая добавленная стоимость (Economic Value Added, EVA)

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

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

Краткие итоги

Содержание материала выстраивает трёхуровневую рамку, позволяющую осмысленно подходить к внедрению информационных систем: от постановки стратегической цели через организацию проекта к измерению полученного результата. В основе лежит идея систематизации уникального опыта. Без общей системы координат любые два проекта выглядят несопоставимыми, но введение осей «управление» и «средства реализации» превращает хаотичный набор кейсов в обозримое поле с понятными траекториями перехода. Это даёт инструмент для первичного позиционирования компании и выбора логики движения: оставаться в собственной разработке, осваивать типовые продукты или даже возвращаться к уникальной системе, когда типовые не покрывают специфику бизнеса. Важно, что выбор пути невозможен без диагностики зрелости: наличие стратегии бизнеса, поддержки руководства, описанных процессов и адекватной инфраструктуры выступают гигиеническим минимумом, без которого любые расчёты и планы теряют связь с реальностью.

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

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