Содержание курса

• Предмет исследования

• Варианты организации производства

• Жизненный цикл производства информационных систем

• Фаза: Предпроектное исследование. Предмет автоматизации

• Фаза: Предпроектное исследование. Предварительная оценка реализации

• Фаза: Проектирование, дизайн, формирование требований

• Фаза: Разработка (реализация). Планирование работ

• Фаза: Разработка (реализация). Имплементация проектного решения

• Фаза: Внедрение (развертывание), ввод в эксплуатацию

• Роли специалистов а ИТ-производстве

Мы подошли к финальной стадии производства Информационной системы (ИС).

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

Как и для предыдущих стадий, определим вызовы и цели, с которыми мы подошли к этапу:

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

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

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

• Для старта использования новой системы, необходимо перенести в нее данные из старых систем, подлежащих утилизации, а их объем может быть значительным.

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

1.  Этапы фазы Внедрения

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

1)  В зависимости от характеристики ИТ-проекта базовые параметры проекта определяют общую сложность и диктуют выбор подхода к внедрению. В данном контексте во внимание принимаются следующие характеристики:

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

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

• Архитектура решения. Напрямую влияет на стратегию развёртывания.

2)  В зависимости от характеристики организации-заказчика. Успех внедрения напрямую зависит от готовности компании и ее сотрудников к изменениям. Внимание уделяется следующим аспектам:

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

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

• Бюджет и ресурсы. Финансовые возможности компании определяют не только выбор продукта, но и влияют на выбор используемых методик.

• Критичность внедряемой ИС для бизнеса. Для критичных систем часто применяют: параллельную эксплуатацию, опытную эксплуатацию, поэтапный запуск.

• Территориальная расположенность. Наличие филиалов и прочее.

3) Выбранная методология и стратегия внедрения. Это непосредственный инструментарий, который определяет конкретный состав этапов и используемые методики. Например: Классические методологии (Waterfall, PMBOK, PRINCE2); Гибкие методологии (Agile, Scrum, Kanban); Управление изменениями (Change Management).

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

1.1.  Этап 1. Планирование этапа внедрения

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

Методика и инструменты планирования этапа стадии Развертывания и внедрения в большой степени совпадает с описанными для предыдущей фазы.

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

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

1.2.  Этап 2. Развертывание системы на площадке опытной эксплуатации

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

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

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

Эти работы выполняют Системные администраторы, в профстандарте представлен как: “Системный администратор информационно-коммуникационных систем. Код_06.026”, Technical – Архитектор, в профстандарте ближе всего “Специалист по поддержке программно-конфигурируемых информационно-коммуникационных сетей. Код_06.037”, Специалисты по безопасности сетей в профстандарте представлен как: “Специалист по безопасности компьютерных систем и сетей систем. Код_06.032”.

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

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

Если внедряемая ИС интегрируется другими системами и сервисами, то в работу включается Интеграторы. В профстандарте: “Специалист по интеграции прикладных решений. Код_06.041”.

Критическими факторами успеха данного этапа являются:

• Наличие детального плана развертывания. 

• Автоматизация процесса. Использование скриптов и инструментов для развертывания.

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

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

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

1.3.  Этап 2.  Обучение заказчика работе с Информационной системой

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

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

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

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

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

1)   Анализ потребностей в обучении:

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

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

2)  Разработка программы обучения:

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

• Планирование форматов обучения. Выбор методов обучения, таких как очные тренинги, вебинары, онлайн-курсы или комбинированные подходы.

3)  Проведение обучения:

• Организация учебных сессий. Проведение тренингов и семинаров с учетом графика работы сотрудников и доступности ресурсов.

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

4)  Оценка эффективности обучения:

• Тестирование знаний. Проведение оценочных мероприятий для проверки усвоения материала.

• Сбор обратной связи. Анализ отзывов пользователей для выявления областей, требующих дополнительного внимания или улучшения.

5)  Поддержка после обучения:

• Доступ к учебным материалам. Обеспечение постоянного доступа к ресурсам обучения для самостоятельного изучения или повторения.

• Техническая поддержка. Предоставление каналов связи для оперативного решения возникающих вопросов и проблем при работе с системой

Эти работы выполняют Специалисты по работе с заказчиком и Специалисты внедрения, в профстандарте ближе всего “Специалист по информационным системам. Код_06.015”.

1.4.  Этап 3. Передача Информационной системы в Опытную эксплуатацию.

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

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

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

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

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

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

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

Но это состояние длится не долго. Потому, что его вытесняет вторая стадия – Отрицание. У людей возникает локальный, частнособственнический вопрос: “А зачем это лично мне? Работает и не трогайте!”.

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

Стратегия управления этими факторами следующая:

• Четкая коммуникация. Объясните почему эти изменения необходимы, какие проблемы бизнеса они решат и почему старый путь больше не приемлем.

• Фокус на причинах. Акцентируйте внимание на текущих сложностях, задержках и ошибках, которые поможет устранить новая система.

• Общее видение. Сформулируйте и донесите яркую картину будущего после успешного внедрения.

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

Стратегия управления этими факторами — вовлечение и эмпатия:

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

• Назначьте «агентов изменений». Найдите и поддержите тех, кто уже видит пользу в новой системе. Они станут вашими лоббистами и примером для других.

• Снимите страхи. Ответьте на ключевые вопросы. «Не устареют ли мои навыки?», «Как изменится моя роль?», «Не потеряю ли я влияние?»

Далее обычно следует стадия — Разочарование (Торг). Люди тратят свое время на попытки убедить себя и окружающих в том, что стало хуже. Начинают подгонять результаты изменений, под свои негативные оценки. Все уверены, что процесс еще возможно отменить, что осознав всю глубину ошибочности решения, будет найден компромисс и все просто вернется на круги своя. Они могут предлагать использовать новую систему лишь частично, сохранив старые методы для самых важных задач. Или пытаются договориться о том, чтобы их обязанности изменились не так сильно. Это попытка смягчить удар и сохранить зону комфорта.

При этом, продолжают работать неэффективно.

Стратегия управления этими факторами — обучение и демонстрация пользы:

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

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

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

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

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

Стратегия управления этими факторами — поддержка и быстрое решение проблем:

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

• Контекстная помощь. Внедрите подсказки и руководства прямо в интерфейсе новой системы.

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

В дальнейшем, выжившие переходят в стадию – Эксперимент. Происходит попытка отказа от старых моделей поведения, но новые все еще не выработаны.

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

Стратегия управления этими факторами – закрепление результата и масштабирование успеха:

• Обновление стандартов. Закрепите новые правила работы в корпоративных регламентах и системах мотивации.

• Создание культуры. Поощряйте обмен опытом и лучшими практиками между сотрудниками.

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

На этом этапе существует серьезный риск застрять в “Долине слез”. Этот термин описывает ситуацию, когда после неудачных попыток примерить новые правила, мы откатываемся к предыдущему этапу — Депрессии. И этот цикл повторяется, пока не будет найден новый подход и методы работы.

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

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

Высшая стадия – Интеграция. Если мы говорим о внедрении изменений в компании, то после всего этого требуется встраивание изменений в корпоративную культуру. При достижении положительного результата, наступает всеобщее “просветление”.

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

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

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

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

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

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

1.5.  Этап 4. Выявление недостатков и дефектов внедренного решения

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

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

Эти работы выполняют Архитекторы и Системные аналитики с помощью Специалистов внедрения.

Для эффективного и качественного проведения этих работ уже на этапе опытной эксплуатации обычно проводят Приемочные испытания внедряемой ИС.

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

По видам приемочные испытания делятся на:

• Пользовательское (UAT). Соответствие бизнес-процессам, удобство работы, решение реальных повседневных задач.

• Эксплуатационное (OAT). Надежность, восстанавливаемость, совместимость, производительность в рабочей среде, готовность службы поддержки.

• Бизнес-приемочное (BAT). Соответствие финансовым и рыночным целям (достижима ли окупаемость, не нарушает ли продукт рыночную стратегию).

• Контрактное (CAT). Соответствие формальным условиям контракта и соглашениям об уровне услуг (SLA).

• Регуляторное/Правовое (RAT). Соответствие законодательству, отраслевым нормам и стандартам безопасности (например, 152-ФЗ о персональных данных, ISO, PCI DSS).

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

1. Объект и цели испытаний.

2. Объем проверок (какие функции проверяем, а какие — нет).

3. Критерии приемки (Entry/Exit criteria).

4. Порядок и условия проведения.

5. Методы обработки результатов.

Сам процесс тестирования определяется детальными инструкциями для проверяющих — Тестовыми сценариями и тест-кейсами. В современной практике (особенно в Agile) их часто описывают на языке Gherkin (Given-When-Then), что делает сценарии понятными и для бизнес-пользователей.

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

Заключение о соответствии системы требованиям и решение о вводе в эксплуатацию или отправке на доработку содержатся в итоговом документе — Акт приемки-сдачи, который подписывается сторонами.

1.6.  Этап 5. Передача системы в промышленную эксплуатацию

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

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

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

1)  Подготовка и предъявление. Исполнитель формирует и передает заказчику пакет отчетных документов, уведомляя о готовности системы к сдаче.

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

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

4)  Анализ результатов. Комиссия оценивает полноту и качество выполнения всех требований ТЗ, готовность персонала и документации.

5)  Принятие решения. Комиссия голосованием принимает одно из решений:

• Система соответствует требованиям и может быть принята в эксплуатацию.

• Система требует доработки (с указанием срока и перечня недостатков).

• Система не соответствует требованиям и не может быть принята.

6)  Подписание акта. При положительном решении подписывается Акт сдачи-приемки. Этот момент часто является юридическим основанием для окончательной оплаты работ исполнителю.

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

2.  Место фазы Внедрения в ЖЦ производства

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

Если рассмотреть распределение активов ЖЦ по стадиям производства ИС, то часто на фазу внедрения может приходиться значительная доля.

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