Счастливая ИТ-система

  • Системный анализ, как игра: Часть I, Топливо для мотивации В чем смысл работы системного аналитика? На мой взгляд - в обнаружении вариантов решения задачи и содействии выбору наиболее подходящего. Возможно, кому-то из вас уже приходилось видеть скучные бестелесные постановки ...
    Posted Feb 21, 2020, 12:22 PM by Alexander Stepanov
Showing posts 1 - 1 of 1. View more »

Консультационная услуга "Счастливая ИТ-система"


Навигатор в океане проектных возможностей и рисков: поддержка заказчиков и исполнителей в проектах внедрения систем класса ERP (MRP, WM, TM, CRM), BPM, BI, AI и производных решений для автоматизации бизнеса - это альтернатива интуитивному и стихийному управлению проектом внедрения.

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

Диагностика

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

Анализ

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

Проектирование

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

Производство

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

Развертывание и запуск

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


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

Мой инструментарий

Что же мешает многим проектам внедрения ИТ-систем достичь максимальной эффективности? Отсутствие четкого целеполагания, отсутствие четкого образа будущего решения и его бизнес-ценности, отсутствие четкого плана движения к цели - не понимание задач, которые нужно решить. Это самые важные факторы любого проекта. Поэтому для каждого проекта я синтезирую "экземпляр" методологии, адаптируя ее под специфику проекта. Вот мои основные ингредиенты (так сказать, "базовые классы"):
  • Архитектурный подход (Enterprise Architecture), который связывает воедино мотивацию (миссию, стратегические цели, бизнес-драйверы / факторы) с бизнес-архитектурой, архитектурой информации, архитектурой приложений и ИТ-инфраструктурой.
  • Процессы жизненного цикла систем (ИСО/МЭК 15288).
  • "Учение" Генри Минцберга о базовых формах организационного управления.
  • Авторский подход на основе типового цикла управления (типовые задачи управления + замкнутые контуры управления с обратной связью): позволяет вести диалог с заказчиком - прояснять содержание проекта и формировать облик будущего решения для автоматизации.
Это арсенал средств для преодоления множества проблем. Но помните, что "методология" - не значит "теория" или "много текста и слов". В ряде случаев очень многое можно выразить графом, умещающимся на одной странице ("картой знаний"). Методология - это способ мышления, позволяющий построить дорожную карту проекта внедрения, и удержать проектную команду на маршруте движения к цели.