Автоматизация в условиях неопределенности

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

"Познание бесконечности требует бесконечного времени".
Аркадий и Борис Стругацкие "Понедельник начинается в субботу"

Ситуации с высокой степенью неопределенности характерны практически для любой компании в стадии изменений. Вот только несколько примеров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

***

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