Применение знаний из области разработки ПО к разработке бизнес-процессов

Многим уже известны результаты статистики - 60% всех проектов по разработке программного обеспечения не завершаются с успехом.

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

Если 60% всех процессов переработки проектов терпят крах, то что же нужно предпринять, чтобы избежать данную вероятность и добиться улучшения результатов?
Посредством использования гибких процессов перестройки (Agile) , принятых в индустрии разработки ПО.

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

Так, а какое отношение это имеет к разработке бизнес-процессов?

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

1. Документация старых процессов в четких деталях (примерно 2 недели времени)
2. Определение проблем старого процесса (примерно неделя)
3. Разработка этапов для новых процессов (примерно неделя)
4. Разработка деталей новых процессов (минимум четыре недели)
5. Реализация всего этого в одном большом проекте (не стоит даже гадать...)
6. Надежда на то, что все сработает (и что разработка все еще будет релевантной после всего этого времени)

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

Но так не должно быть.

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

Урок #1: минимальный рабочий процесс

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

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

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

Урок #2: продолжительная разработка и внедрение

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

1. Вы можете работать тесно с клиентом для понимания и создания ПО.
2. Вы выпускаете ПО в виде маленьких блоков функциональности.
3. Вы наблюдаете и исправляете.
4. Вы опять осуществляете выпуск.

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

Вы уже могли бы задаться вопросом о том, что же вам для этого необходимо делать? Что, если все пойдет не так? Вам необходимо проводить тестирование, анализ выгодности затрат, оценку руководства, финансовые обзоры, юридические одобрения и другие обзоры до того, как вы сможете что-либо сделать. Такие небольшие выпуски легче держать под контролем, при этом проблемы легче определить по сравнению с ситуацией, когда вы производите один большой выпуск в конце разработки процесса. Также риски можно "упаковывать" в более мелкие управляемые куски для обеспечения того, что вы не
пойдете ва-банк со своей новой разработкой продукта. Попробуйте перейти в массивную реализацию процесса после 8-10 недель разработки и попробуйте определить проблемы (или выгоду), которые связаны с тем, что вы уже реализовали - вот это будет рискованно!

Урок #3: тестирование процессов по методу A/B тестирования

Итак, вы создали наименьший, наиболее вероятный процесс, вы реализовали его при помощи продолжительных методик, а теперь что? Теперь вам стоит протестировать результаты. Зачастую реализация процессов ощущается как одноразовая процедура. Мир разработки ПО научил всех тому, что стоит постоянно изучать эффективность каждого выпуска. Представьте себе ПО, которое было выпущено, но с ошибками, которые никогда не были исправлены - такое ПО никто не будет использовать, и уж тем более рекомендовать. В среде гибкой разработки ПО существует такая техника A/B тестирования или "раздельное тестирование", которое используется для определения последствий последнего выпуска.

Вот как работает A/B тестирование: вы выпускаете небольшие разработки, поэтому каждый набор функциональности относительно легко понять касательно последствий для пользователей. При выпуске данного изменения функциональности ("A"-функциональность), вы внедряете его для подгруппы пользователей и сравниваете результаты со старой группой, которая использует старую функциональность ("B"-функциональность). Представьте себе это как бета-тестирование. Это может иметь значительный положительный эффект на ПО, и вам конечно захочется определять все проблемы как можно быстрее.

Используйте принцип A/B тестирования для ваших изменений бизнес-процессов. Вместо выпуска измененной формы, веб-сайта или процесса для всех пользователей, осуществите выпуск только для части и сравните разницу. А новый процесс настолько же хорош, как вы и ожидали? Если да, то вы можете выпускать следующую часть для новых пользователей, а если нет, то вам стоит переработать нововведения процесса и повторно осуществить выпуск. Продолжительное внедрение и A/B тестирование тесно связаны в цикле разработки, внедрения, тестирования и повторной разработки. Помните, что A/B тестирование без продолжительного внедрения будет подразумевать длительное наличие ошибок в выпущенной программе, а применение тактики длительного внедрения без A/B тестирования означает, что проблемы останутся надолго незамеченными.