Внедрения бекофисных информационных систем. Waterfall vs Agile.

Бекофисные информационные системы (БИС) и особенности хи внедрения.

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

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

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

Следовательно, для правильной автоматизации БП нужно  формализовать эти БП, а потом заниматься их автоматизацией и/или роботизацией.

Часто также ставится задача по оптимизации БП, цель которой может быть различна.

В итоге  выстраивается четкая последовательность действий, которые должны быть предприняты в рамках внедрения БИС:

  1. Формирование замкнутой модели БП.
  2. Формализация бизнес процессов до необходимого уровня.
  3. Проведение оптимизации БП.
  4. Разработка новых регламентов БП.
  5. Выбор оптимальной платформы для автоматизации БП.
  6. Оценка бюджета и сроков внедрения БИС.
  7. Внедрение ИС.

Что важно в проектах внедрения БИС.

Все мы знаем о треугольнике:

  1. Качество.
  2. Срок.
  3. Бюджет.

Все три параметра важны для компании.

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

Это приводит к нас к выводу, что проект необходимо таже разделить на две крупные части:

  1. Консалтинг по БП.
  2. Внедрение ИС.

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

В результате мы получаем следующую последовательность:

  1. Консалтинг.
    1. Аудит БП.
    2. Оптимизация БП.
    3. Выбор платформы.
    4. Оценка сроков и стоимость по внедрению.
  2. Внедрение БИС.
    1. Моделирование БП.
    2. Написание ЧТЗ.
    3. Разработка.
    4. Тестирование.
    5. Подготовка к ОПЭ.
    6. ОПЭ.
    7. Уход в ПРОМ эксплуатацию.

Именно такой подход ведет к сокращению всех возможных рисков проекта.

Два типа методологий ведения проектов.

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

Давайте сначала посмотрим более пристально на эти методологии, а потом порассуждаем относительно их противопоставления.

Что такое Waterfall в проектах внедрения информационных систем (ИС).

Определение — Каскадная модель (англ. waterfall model, иногда переводят как модель «Водопад») — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

Теперь давайте посмотрим на эту модель применительно к внедрению ИС.

Выше мы уже определили правильную последовательность внедрения при которой минимизируются риски проекта. И мы видим, что это ни что иное как каскадная модель или иначе Waterfall.

Т.е. минимизация рисков на проекте напрямую зависит от четкой последовательности действий. Что и является тем самым водопадом — Waterfall.

Что такое Agile.

Определение — Гибкая методология разработки (англ. Agile software development), agile-методы — обобщающий термин для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе.

К гибким методологиям, в частности, относят экстремальное программированиеDSDMScrumFDDBDD и др.

Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с управлением ими комбинированным (либеральным и демократическим) методом.

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

Итак, важно, каждая отдельная итерация по факту отдельный мини проект со своим результирующим продуктом!

Это означает, что это полностью самостоятельно функционирующий результат.

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

Попытка использовать Agile для внедрения БИС будет приводить наоборот к возрастанию рисков проекта, отсутствию понимания итогового результата, отсутствию гарантий по бюджеты и срокам проекта!

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

Waterfall и Agile — друзья или враги?

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

Однако давайте посмотрим на такие этапы как:

  1. Формализация БП.
  2. Оптимизация БП.
  3. Написания ЧТЗ.
  4. Разработка.

Внутри каждого такого этапа имеется много однотипных по сути работ которые могут выполняться параллельно и не в жесткой последовательности.

Так при формализации различных бизнес процессов вы можете сформировать несколько маленьких групп, каждой из которых будет отведем свой набор БП для формализации, что является тем самым беклогом (набором задач), который применяется в методологии Agile и в любом из его вариантов — Канбан или Scrum.

Аналогичная ситуация с остальными этапами, даже при написании ЧТЗ — т.к. это тоже набор документов, которые в 1С часто называются ФДПР (функциональные дизайны программных расширений).

При разработке тоже самое.

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

Вывод №1 — применение Agile в чистом виде при внедрении БИС несет очень большие риски сравнительно с Waterfall, однако при этом Agile является замечательным дополнением к водопаду даже при внедрении БИС и позволяет гибко управлять работами в рамках отдельных этапов!

Вывод №2 — если внедряете не БИС, а что то иное, например фронтенд систему, то в этом случае итеративность Agile может быть эффективнее Waterfall, но вам может потребоваться каскадный подход в отдельных итерациях разработки.

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

Добавить комментарий