Коротко
В статье показана важность учёта будущего развития бизнеса при проектировании системы.
В первой части показано, что показатель стоимости будущих доработок системы может рассматриваться как ключевой при разработке ИТ-систем.
Во второй части, показано, как меняется фокус анализа в зависимости от модели поддержки будущих изменений в системе. Описаны изменения в процессе проектирования, которые появляются при ориентации на будущие изменения в бизнесе. Новый подход к проектированию даёт возможность моделировать систему в разных стилях, которые перечислены в статье.
Введение
Суть проектирования ИТ-системы заключается в создании модели окружающего мира, материализованной в ИТ-инструментарии. Окружающий нас мир многогранен и содержит в себе бесконечное множество моделей, которые в нём можно увидеть и извлечь из него. Поэтому разработка ИТ-модели это не формальный, а творческий процесс. Однако, стандартный процесс проектирования, сфокусированный на анализе существующих требований, весьма детерминирован и отводит очень мало места творческому осознанию истинного предназначения системы. Для того чтобы понять, почему систему, которая полностью удовлетворяет заказчика нельзя назвать идеальной, достаточно задаться вопросом: «Насколько эффективной окажется внедрённая система в будущем? Точнее, насколько она будет способна поддержать новые требования, которых на момент её разработки нет? Или, какова суммарная стоимость доработок системы под новые требования бизнеса?». Ответ на этот важный вопрос определяет стоимость использования системы в будущем и возможность быстрого внедрения инноваций в бизнесе. От него зависит, станет ли система «якорем» бизнеса, или его «организующим началом». Выявление возможных будущих требований приводит к новому видению концептуального проектирования, которое даёт качественно новые результаты для бизнеса и открывает новые горизонты для развития подходов к проектированию систем.
Стоимость будущих доработок – важный критерий качества продукта
Традиционно качество разработанного программного продукта оценивается по соответствию требованиям, количеством дефектов, выявленных при тестировании, количеством патчей, установленных после внедрения в продуктив, соответствием инфраструктуре, качеством документации и т.д. Иными словами - степенью удовлетворения всех требований заказчика по окончании внедрения. Однако, успешно внедрённая система, может оказаться неспособной к изменениям вместе с бизнесом. Так, простое изменение организационной структуры может драматически сказаться на удобстве использования системы в новых условиях. Или новые прибыльные идеи могут быть отвергнуты ввиду высокой стоимости доработки системы.
Здесь хотелось бы привести пример из личного опыта. В одном из регионов крупной компании была внедрена перспективная схема мотивации продавцов, которая обеспечивалась ИТ-системой, разработанной специально для этой цели. Затем было принято решение распространить позитивный опыт на другие регионы. Изначально планировалось доработать эту систему для использования её в различных регионах. Однако, после детального изучения архитектуры объектов и алгоритмов её работы оказалось целесообразнее заново её переписать, а не дорабатывать. На момент запуска второй версии по всей стране, кроме региона-родителя, обе системы выполняли одну и ту же функциональность и были реализованы по сходным требованиям, т.е. для бизнес-заказчика были равноценны. Однако, уже через два года первая система была неспособна поддержать изменения в схемах мотивации, т.к. её доработка обходилась все дороже и дороже ввиду неоптимальной архитектуры объектов. Наконец, разработка в ней была заморожена, и регион перешел на вторую версию (которую уже использовали другие регионы) и в которую были заложены те требования, которые не были выдвинуты заказчиком на момент создания системы, но их можно было предположить в будущем.
С момента внедрения система начинает влиять на бизнес так же, как бизнес влияет на развитие системы. Она, как наложенный на бизнес шаблон, поощряет его развитие в одном направлении и ограничивает в другом. Думаю, никто не будет спорить, что если предложение поддержать в системе новую идею будет оценено в «$500 тыс. и 1 год», то едва ли идея будет реализована. И наоборот, если на вопрос «А ЭТО система может?» получен ответ «Да, может! Надо только настроить», то автоматизация не будет препятствием на пути реализации бизнес-идей.
Интересно отметить, что ответ ИТ «Нет» или ответ «Да» бизнес воспринимает как данность и не пытается ему воспротивиться. В первом случае он считает ИТ дорогой неповоротливой машиной, без которой, увы, не обойтись, а во втором – он работу ИТ просто не замечает и воспринимает отсутствие «ИТ-сопротивления» почти как должное. Истину для владельца может приоткрыть ИТ-аудит.
Нужно отметить, что локальные внедрения плохо спроектированных, неповоротливых ИТ-систем могут оказаться достаточно живучими. Плохие системы требуют регулярного вливания средств как в разработку, так и в поддержку. А для отказа от неудачной системы (если даже это понимание есть) необходимо заново пройти весь путь автоматизации сначала для создания новой ИТ-системы, которая является «хребтом» бизнес-процессов. Поэтому бизнесу нужно уметь защищаться от «ИТ-паразитизма».
Приведу ещё один пример из опыта. Была разработана аналитическая система дашбордов для менеджмента, в частности, для генерального директора. Система реализовывала сбор данных из разных источников и их многоуровневую агрегацию в витринах с помощью высокотехнологичного ИТ-инструмента. Набор ключевых показателей выводился в пользовательском интерфейсе наглядно, в графическом виде, с возможностью интерактивного отбора данных. Это был красивый и современный аналитический инструмент, встреченный менеджментом с одобрением. Первоначальный набор отчётов был определен гендиректором. Однако, через непродолжительное время после внедрения системы он сменился, а новое руководство потребовало новых отчётов и скорректировало алгоритмы расчёта показателей. Управленческие данные нужны оперативно, а система была неспособна быстро трансформироваться под новые требования, и работы по созданию отчётов нового формата были возложены на бизнес-подразделения в старом добром Excel-е. Система фактически была дискредитирована и выведена из эксплуатации.
Таким образом, корректность видения будущего развития системы в момент разработки определяет стоимость её дальнейших доработок и уровень лояльности бизнеса по отношении к ней в будущем. Не это ли важная составляющая TCO[1], которая, увы, не учитывается? Но возможно ли получить оценку стоимости будущих доработок? Как можно ориентироваться на требования, которых нет?
В предсказании будущего, или отражении сути процессов, которые автоматизируются системой, заключено качество модели и качество системы. Включение в модель будущих сценариев развития бизнеса открывает, с одной стороны, новые области для развития стилей проектирования и возможности для проявления творческого потенциала проектировщика системы, а с другой стороны, даёт значимый результат для бизнеса.
Реализм, импрессионизм, кубизм…
Подобно тому, как различные техники письма порождают разные живописные стили, моделирование действительности через ИТ-проектирование также осуществляется с использованием различных приёмов, которые можно объединить в стили. Каждый из этих стилей по-своему решает задачу создания видения будущего. Объём данной статьи слишком мал для того, чтобы подробно описать каждый из стилей, поэтому ограничимся лишь кратким их описанием. Приведённый ниже перечень не претендует на полноту, перечислены лишь некоторые стили проектирования, которыми пользуется автор.
Классицизм – данный стиль фокусируется на реализации существующих требований заказчика. Особенно внимательно должны собираться требования к будущим бизнес-процессам или пожелания по улучшению существующих процессов.
Цель: полностью удовлетворить желания заказчика.
Границы проекта: реализация согласованных с заказчиком требований.
Достоинства: заказчик получает то, что хотел.
Недостатки: система способна поддержать лишь те изменения, которые были заложены в неё заказчиком.
Универсализм – суть данного стиля в том, чтобы заложить в систему все возможные сценарии развития бизнеса.
Цель: создать полностью универсальную систему, которая сможет в дальнейшем поддержать любые изменения в бизнесе.
Границы проекта: реализация выявленных и согласованных с заказчиком текущих и максимально возможных будущих требований к системе.
Достоинства: cистема не потребует доработки программного кода даже в случае непредвиденных изменений в процессах.
Недостатки: cистема-конструктор, может оказаться очень сложной и дорогой в разработке и поддержке. Широкие возможности порождают сложные настройки под конкретную реализацию. Настройка системы может превратиться в отдельный проект. Вариативность архитектуры целесообразно использовать только в тех случаях, когда риски по изменению бизнес-процессов велики.
Концептуализм – суть данного стиля заключается в том, что требования заказчика являются лишь исходным материалом для создания идеального бизнес-процесса и идеальной системы.
Концептуальный подход эффективен в случаях, когда ни один из участников бизнес-процесса, не знает весь процесс в деталях. Такое бывает в сложных системах. Каждый из участников знает только малую часть и транслирует проектировщику свои «боли» и пожелания по своему кусочку процесса. В таких случаях требования заказчиков фрагментарны и конкретны. Ситуация подобна описанной в «Притче о слепых мудрецах, которые ощупывали слона» - каждый видит свою «картинку».
В результате «прохода по процессу» интервьюированием цепочки заказчиков, у аналитика рождается полная картина процесса. Её осознание и формализация дают новое понимание реализации бизнес-процесса и путей его оптимизации. Фактически сбор требований в этом случае превращается в консалтинговые работы по оптимизации бизнес-процессов (которые в идеале и должны предшествовать автоматизации). Новый идеальный бизнес-процесс может убрать ненужную специфику, порождённую амбициями конкретных исполнителей, и реализовать простой и понятный всем концепт.
Из множества пожеланий проектировщик рождает собственное видение системы. Это видение требует представления и согласования с менеджментом и является фактически сотворчеством в создании будущего бизнеса.
Цель: создать модель системы и бизнеса, способную к самостоятельному развитию в рамках выбранной концепции.
Границы проекта: сбор максимально широкого набора требований, построение на их основе концептуальной модели системы и бизнеса, реализация согласованного ограниченного набора требований в рамках выбранной концепции. Остальные требования, которые не вписываются в концепт, признаются нецелесообразными для реализации.
Достоинства: система имеет целостную концепцию и идеологию построения. В случае, если бизнес развивается в том же направлении, что и избранная концепция, система открывает новые возможности для развития и оптимизации бизнес-процессов и поддерживает вектор развития без особых затрат.
Недостатки: в случае, если развитие бизнеса идёт вразрез с выбранной концепцией системы, она становится очень неудобной в эксплуатации и трудоёмкой при доработках.
Данный стиль проектирования целесообразно использовать, если соавторами модели являются менеджеры компании. Концептуальный стиль наилучшим образом организует информационные потоки в компании, но требует высокой квалификации проектировщика и глубокого понимания автоматизируемого бизнеса. При концептуальном проектировании очень важна связь команды разработчиков с постановщиками задачи. Концептуальную модель системы необходимо «продать» бизнесу. Обычно внедрение такой системы приводит к пересмотру некоторых бизнес-процессов и альтернативной реализации некоторых операций.
Вместо заключения
Система, неспособная поддержать изменения или тормозит бизнес, или умирает. Грамотное комбинирование стилей проектирования в различных частях системы рождает неповторимое произведение проектировщика – модель, красоту которой иногда можно оценить сразу, а в большинстве случаев - лишь со временем…
[1] TCO – total cost owner – совокупная стоимость владения – общая стоимость затрат на ИТ за весь цикл жизни ИТ-продукта, включая разработку, поддержку, доработки, расходы на «железо» и т.п.