Оргинал: Business automation best practices
Автор: Сэнди Кемсли (Sandy Kemsley)
В нашем распоряжении много крутых технологий автоматизации бизнес-процессов и бизнес-правил:
- автоматизация процессов с помощью систем управления бизнес-процессами (BPM, business process management) и кейс-менеджмента
- автоматизация задач с помощью роботизации процессов (RPA, robotic process automation) и вызова сервисов посредством API
- автоматизация принятия решений с помощью систем бизнес-правил
- плюс интеллектуальные технологии широкого применения, такие как искусственный интеллект и машинное обучение, делающие процессы и решения умнее
Эти технологии открывают возможности более глубокой автоматизации. Они позволяют не только автоматизировать лучше и быстрее — теперь мы можем автоматизировать то, что раньше автоматизировать не представлялось возможным. Но есть и оборотная сторона: доступ к этим технологиям есть не только у вашей компании — другие тоже стремятся автоматизировать свой бизнес, используя те же методы и те же технологии. Это означает, что в какой бы отрасли вы не вели бизнес, она становится все более конкурентной. Приливная волна новых технологий поднимает все лодки, а не только вашу. Под давлением более динамичных конкурентов вам придется либо автоматизировать свою деятельность, либо уйти с рынка. Императив автоматизации — автоматизировать бизнес необходимо, иначе просто не выжить.
Так что, просто включили какие-то новые технологии и вперед? К сожалению, не все так просто. Как показало исследование Boston Consulting Group, 70% проектов цифровой трансформации не достигают поставленных целей. 70 процентов! Это много. Ну хорошо, цифровая трансформация — это очередной расплывчатый термин, который сегодня употребляется по отношению практически к любому ИТ-проекту, поэтому давайте вникнем поглубже. Компания Ernst & Young изучила проекты RPA. По уверениям поставщиков программного обеспечения RPA, инвестиции в RPA окупятся еще до того, как они выйдут из вашего офиса.
Однако, как обнаружили в E&Y, от 30 до 50 процентов первоначальных попыток внедрить RPA терпят неудачу. Но если компаниям не удается добиться успеха с помощью наиболее безрисковой, по общему мнению, технологии автоматизации, то конечно это может быть связано с проблемами ПО, но мы можем также предположить, что кое-кто как-то неправильно его внедряет. Мы тратим миллиарды долларов на ИТ-проекты, которые в итоге проваливаются.
Неудачи в автоматизации бизнеса терпят многие компании, но вы не обязаны быть одной из них. Давайте рассмотрим лучшие практики, максимально повышающие шансы на успех проектов автоматизации бизнеса. (Или, если взглянуть с противоположной стороны, сводящие к минимуму риск провала.)
- В первую очередь мы рассмотрим лучшие практики стратегического планирования. Речь пойдет о разработке приложений как реализации стратегии автоматизации бизнес-процессов и автоматизации бизнеса.
- Затем мы поговорим о лучших практиках проектирования. Это по-настоящему важно, если большую часть разработки приложений вы ведете собственными силами. Проектирование — это то, чем я в основном занимаюсь, так что здесь мне есть чем поделиться.
- В завершение мы рассмотрим лучшие практики в области методологии — как инициировать и управлять проектами разработки бизнес-приложений и как внедрять приложения в эксплуатацию.
Я расскажу, что рекомендуется делать по каждому из этих направлений. Мы также обсудим признаки того, что вы идете неверным путем. Обнаружив в своем проекте какие-то из антипаттернов, вы сможете скорректировать его до того, как будет слишком поздно.
1. Лучшие практики стратегического планирования
1.1 Стратегическая значимость
Первая лучшая практика — сделать автоматизацию бизнеса стратегическим направлением развития компании. Недостаточно, чтобы инициатива автоматизации просто получила одобрение со стороны высшего руководства или чтобы она стала любимой игрушкой кого-то из топов. Автоматизация должна быть заявлена в качестве стратегии развития компании на самом высоком уровне. На недавней конференции CIO правительства штата презентовал текущие стратегические инициативы, и одной из них была названа автоматизация процессов.
В качестве обоснования он сказал, что автоматизация уменьшает объем рутинной, повторяющейся работы и позволяет сосредоточиться на более полезной работе, требующей участия человека. Автоматизация бизнеса является общепризнанной движущей силой стратегического развития: она обеспечивает и стимулирует инновации, повышение производительности, глобализацию и другие инициативы. Если компания не рассматривает автоматизацию в качестве стратегической корпоративной цели, то ваш проект автоматизации находится под угрозой.
Проекты автоматизации могут быть сложными, они могут длится долго и приводить к масштабным изменениям. Без «воздушного прикрытия» со стороны высшего руководства такой проект легко можно обнаружить лежащим на обочине, беспомощно дрыгающими ножками в то время, как мимо в своем лимузине проносится руководство в погоне за очередным блестящим пузырем.
1.2 Выбор подходящего процесса
Вторая лучшая стратегическая практика, особенно актуальная для начальных проектов, это выбор правильного процесса. Никого не впечатлит, что у вас лучший в мире процесс составления авансового отчета. Но всех по-настоящему волнует, чтобы основные процессы были эффективными, инновационными, выделяющими вас из ряда конкурентов.
Это не значит, что авансовые отчеты не следует автоматизировать — это значит, что в первую очередь вы должны сосредоточиться на основных процессах, потому что здесь результаты ваших усилий будет максимально заметными.
За многие годы участия в реальных проектах автоматизации бизнеса мне приходилось слышать от многих — от вендоров, от консультантов, от внутренних участников проектов — предложение взять для пилотного проекта менее рискованный процесс. Но вы не узнаете, как автоматизация бизнеса способна преобразить вашу организацию, пока не внедрите ее в своих основных процессах.
Вы ведь не занимаетесь тестированием технологии — она уже зарекомендовала себя как надежная, речь не идет о супер-новых технологиях. Вы лишь изучаете возможность применения этих новых для вас технологий в собственной деятельности. Вот где вам необходимо продемонстрировать успех.
Выберите основной операционный процесс, ключевой с точки зрения бизнеса. Не стремитесь автоматизировать «все и сразу» — автоматизируйте выбранный процесс настолько, чтобы можно было продемонстрировать измеримую пользу, а также потенциальный эффект при масштабировании первоначального проекта.
Отсюда вытекает один из главных индикаторов проблемности вашей инициативы автоматизации: никому нет дела до процесса, который вы автоматизируете. В этом случае надо осмотреться и выяснить, где вы сбились с курса. Выбранный процесс должен иметь определенную стратегическую значимость. Вы должны быть в состоянии продемонстрировать эффект более значимый, чем простое сокращение трудозатрат подразделения. Даже если вы автоматизируете процесс уровня подразделения, например такой, как оплата счетов, у вас есть возможность показать, как улучшение этой операции скажется на других, связанных с данной. Для начала, в качестве результатов можно показать оптимизированный поток денежных средств, сокращение потерь из-за просрочек платежей, улучшение взаимоотношений с поставщиками.
Итак, выбирая процесс для начального проекта, убедитесь, что он представляет реальный интерес с точки зрения бизнеса.
2. Лучшие практики проектирования автоматизации
2.1 Показатели
О показателях зачастую не задумываются до завершения автоматизации процесса, но это совершенно неправильно. Как вы вообще определите, что надо проектировать и внедрять, если не понимаете, что имеет значение? Показатели измеряют то, что важно для вашей организации. Причем речь не только о производительности подразделения — не только о том, чтобы делать все то же самое, но быстрее, качественнее и дешевле. Нужно воспринять архитектурный подход к показателям: начать с корпоративных целей на верхнем уровне, а затем определить показатели сквозных процессов, которые могут охватывать несколько отделов и несколько систем, но в конечном итоге работают на достижение корпоративных целей.
Повышение удовлетворенности клиентов
Предположим, среди корпоративных целей значится повышение удовлетворенности клиентов. (Честно говоря, у кого нет такой цели?) Пока звучит несколько расплывчато, но если вы вникнете в причины недовольства ваших клиентов, то, вероятно, обнаружите, что они связаны с низкоуровневыми операционными показателями, такими как качество, продолжительность цикла, прозрачность процесса. Другими словами, если вы способны обработать заказ клиента правильно с первого раза, сделать это быстрее и в процессе выполнения дать клиенту возможность видеть, что происходит с его заказом, то удовлетворенность клиента повысится.
Теперь о том, как это сказывается на проектировании процесса. Если вы хотите повысить качество выполнения клиентских заказов, то определенно автоматизация — ваш друг. Обратите внимание на те места в процессе, где человек выполняет повторяющиеся задачи и где принимает решения, в которых присутствует риск ошибки. Например, на повторный ввод данных из вебсайта в систему выполнения заказов и на принятие решения о том, какой способ доставки использовать. Затем вы сможете спроектировать автоматизированные интерфейсы между системами и автоматизировать решения на основе четких бизнес-правил. Это повысит точность данных и уменьшит вариативность решений. И то, и другое являются ключевыми факторами, влияющим на качество процесса в целом.
Сокращение времени цикла
Такого типа автоматизация сокращает также время цикла, которе было отмечено выше как второй показатель, связанный с корпоративной целью повышения удовлетворенности клиентов. Будучи автоматизированными, действия и решения выполняются мгновенно, в любое время дня и ночи, не дожидаясь человека и начала рабочего дня.
Прозрачность процесса
Третий показатель, влияющий на удовлетворенность клиентов,- прозрачность процесса. Клиент хочет знать, что происходит с его заказом, и вам надо придумать как это реализовать. Это могут быть уведомления, отправляемые на электронную почту по прохождению определенных этапов. Или это может быть портал, на который клиенты заходят, чтобы проверить статус заказа самостоятельно. Как только вы организуете сквозной процесс, включающий автоматизированные и ручные шаги, выполняемые различными системами и подразделениями, вы сможете добавить контрольные точки, которые дадут клиенту возможность отслеживать свой заказ. В качестве бонуса, предоставив им возможность самообслуживания в части контроля заказом, вы сократите количество звонков в контакт-центр. Одновременное снижение затрат и повышение удовлетворенности — беспроигрышный вариант!
На примере корпоративной цели удовлетворенности клиентов мы показали, как надо транслировать корпоративную цель на уровень операционных показателей. Вы должны быть уверены, что операционные показатели согласованы с корпоративными целями.
2.2 Выясните, как устроен процесс
Вторая лучшая практика проектирования — вы должны выяснить, благодаря чему существующий процесс срабатывает (или не срабатывает). Это не значит, что вы должны проанализировать процесс «как есть» на микроуровне, а потом просто автоматизировать шаги, из которых он состоит. Скорее вам нужно углубиться в процесс, чтобы определить ключевые составляющие успешного выполнения процесса.
Можно начать анализ существующего процесса с применения process mining, но все же главное здесь — найти экспертов, участвующих в процессе, и поговорить с ними. Про это есть отличный эпизод в подкасте Майкла Льюиса (Michael Lewis) «Против правил». Майкл Льюис — это парень, написавший «Moneyball» и еще несколько книг, в которых разбирается почему некоторые вещи в бизнесе устроены так, как они устроены. Этот эпизод называется «на шесть уровней ниже», и в нем рассказывается о выставлении счетов в американской компании из сферы здравоохранения и о том, как они добились успеха за счет глубокого пониманию, когда и какие правила выставления счетов следует применять. Их метод заключался в том, чтобы найти людей, стоящих на шесть ступеней ниже топ-менеджмента. Другими словами, найти людей, которые реально выполняют работу и понимают, как и почему все устроено. Люди, находящиеся на переднем крае процесса, даже если они не взаимодействуют с клиентами, понимают, какие шаги процесса и правила необходимы, а какие нет.
Уделять время специалистам на передовой всегда было одной из составляющих моей работы по проектированию. Я определенно считаю это элементом лучшей практики определения ключевых составляющих процесса, и я полагаю, что вам следует использовать этот метод в ходе проектирования автоматизации бизнеса.
Выяснив, что требуется для успешного выполнения процесса, пора подумать о том, как это встроить в новый автоматизированный процесс. Возможно, некоторые части процесса по-прежнему будут выполняться вручную, потому что в них заключен ваш «ноу-хау». Вероятно также обнаружится многое, что можно автоматизировать. Но начать необходимо с зерна истины — понимания того, что является успешным процессом с точки зрения клиента.
2.3 Два принципа проектирования автоматизации
На первый взгляд может показаться, что они противоречат друг другу, но в действительности это самый главный баланс, который необходимо найти в ходе проектирования.
Первый принцип таков: автоматизируйте все что можно. Если существует технология, позволяющая повысить степень автоматизации вашего процесса, то вы должны ее рассмотреть. Второй принцип: автоматизация не должна исключать человека там, где его участие приносят дополнительную пользу. Другими словами, в погоне за автоматизацией не потеряйте тот существенный вклад, который вносит участие в процессе человека.
Автоматизации должно быть не слишком мало и не слишком много, а в самый раз. Давайте разберемся в этом более подробно.
Отправная точка — мы стремимся автоматизировать все, что поддается эффективной автоматизации. Основные стимулы — повышение производительности, скорости и качества. При правильном подходе, автоматизация позволяет значительно улучшить все эти аспекты. Обратите внимание — я говорю о правильной автоматизации. Причем эти улучшения дают не только улучшение итоговых показателей бизнеса в части затрат, но и увеличение выручки благодаря возросшей удовлетворенности клиентов. Это классический подход к проектированию автоматизации: вы смотрите как работа выполняется сейчас и ищете способ выполнять ее быстрее, лучше и дешевле. Довольно простые приложения могут поднять производительность, экономичность, а зачастую также и удовлетворенность клиентов.
Проще всего начать с автоматизации повторяющихся задач. Вы изучаете отдельные шаги процесса, и если они каждый раз выполняются одинаково или почти одинаково, то скорее всего есть какой-то способ их автоматизировать. Основная идея автоматизации принятия решений, автоматизации или роботизации бизнес-процессов — замена повторяющихся действий, выполняемых человеком, автоматическими шагами. После этого можно рассмотреть более сложные варианты — автоматизацию менее однотипных задач с помощью машинного обучения и искусственного интеллекта. Машинное обучение и искусственный интеллект способны принимать нетривиальные решения там, где это обычно делает человек, учитывая не только контекст текущей операции, но и какие решения принимались в аналогичных ситуациях до того. Автоматизированные системы, научившиеся понимать контекст и историю, обучаются в ходе выполнения однотипных задач точно так же, как это делает человек.
На следующем этапе вы захотите подняться на уровень выше уровня отдельных задач. Теперь вы не просто решаете, автоматизировать отдельные задачи или нет. Любая масштабная автоматизация должна исходить из целей организации и задаваться вопросом — действительно работу ли следует выполнять так, как она выполняется сейчас. Если вы до этого выполняли работу определенным образом, то это не значит, что вы обязаны продолжать выполнять ее так же. Понимание того, что вы хотите получить на выходе конкретного сквозного процесса, дает возможность сделать шаг назад и рассмотреть альтернативные процессы и методы, которые могут выглядеть совершенно иначе, чем то, что вы делаете сейчас.
Помните старый добрый реинжиниринг процессов, идея которого заключалась в радикальном перепроектировании процессов? В чем-то похоже, но теперь у нас появились инструменты, позволяющие спроектировать гораздо более интеллектуальный автоматизированный процесс. Давайте возьмем в качестве примера страховое возмещение. Представьте себе процесс урегулирования страхового случая, в котором полностью автоматизированы сбор данных и документов на старте и принятие решений в некоторых простых ситуациях. Процесс, который был исключительно ручным, благодаря применению спектра технологий полностью трансформируется, и часть претензий теперь обрабатывается без участия человека от начала до конца. Ими не приходится заниматься ни одному сотруднику, они быстрее обрабатываются, в них меньше ошибок ввода данных, а решения принимаются единообразно. Вы выполняете свою работу быстрее, эффективнее и более последовательно, и это делает ваших клиентов счастливыми. Одновременно устраняется множество ручных внутренних операций, и в результате сокращаются затраты. Время квалифицированных работников умственного труда высвобождается для решения сложных проблем и взаимодействия с клиентами, которое автоматизация не заменит.
Но автоматизация — не панацея. Вы должны достаточно хорошо разбираться в своих процессах и своих клиентах, чтобы понимать, где работники умственного труда могут принести дополнительную пользу. Это может быть прямое общение с клиентом в ходе решения сложной проблемы. Чаще всего это происходит, когда стандартный процесс дает сбой, например из-за бракованного товара или нестандартного профиля клиента. Обнаружив это, вы привлекаете работника умственного труда. Вы можете или дожидаться, пока клиент скажет автоответчику или чат-боту «оператор», или сработать на упреждение и распознать необходимость вмешательство человека раньше, чем это поймет сам клиент.
Еще одна типичная ситуация, требующая привлечения работника умственного труда, когда необходимо принять сложное решение, выходящее за пределы текущих возможностей автоматизации. Возвращаясь к примеру со страхованием, мы обнаружим множество претензий слишком сложных для автоматического рассмотрения. Лучше всего с ними справится сочетание автоматизированных задач и работников умственного труда.
В этом суть идеи проектирования автоматизации, излагаемой в этом разделе. Многие процессы не являются полностью автоматизированными или полностью ручными, а представляют собой комбинацию того и другого. Как проектировщик, вы должны понимать, что можно автоматизировать, а что лучше оставить людям. Со временем, по мере того, как технологии становятся умнее, некоторые задачи, которые лучше выполняют работники умственного труда, могут быть эффективно автоматизированы. Применительно к автострахованию, полностью автоматическое урегулирование страховых случаев в прошлом было невозможно, а сейчас практикуется во все более сложных ситуациях.
За последние несколько лет мы неоднократно наблюдали, как решения, которые раньше принимались вручную, теперь автоматизируются с помощью машинного обучения и искусственного интеллекта. Это показывает, что проектирование автоматизации — стрельба по движущейся мишени. Вы должны понимать, какое влияние на ваш бизнес способны оказать новые технологии. Это значит, что необходимо следить за прогрессом технологий автоматизации, выбирая момент, когда их можно будет внедрить в ваши бизнес-операции. Это возвращает нас к тому, о чем шла речь в предыдущем разделе — вы должны понимать ключевые моменты вашего процесса, которые определяют, будет ли он выполнен успешно или завершится неудачей, и исходя из этого определить, какой вклад способны внести люди, а что можно автоматизировать.
2.4 Худшие практики
Поговорим о некоторых распространенных антипаттернах, встречающихся при проектировании автоматизации бизнеса.
Еще до того, как вы приступите к реализации своего проекта автоматизации бизнеса, на этапе формирования требований и проектирования, вы можете увидеть некоторые предостерегающие знаки. Даже если вы практикуете аджайл с его итеративной разработкой, ошибки, допущенные на стадии проектирования, могут иметь далеко идущие последствия.
Антипаттерны на стыке между людьми бизнеса и бизнес-аналитиком
Cамый распространенный из них, по моему опыту — проектировать и разрабатывать то, что бизнес просит, вместо того, что ему нужно. Да, предполагается, что бизнес является полноправным участником проектирования. Но в реальности большую часть своего времени люди бизнеса тратят на выполнение основных обязанностей и у них не остается времени на изучение новых технологий или возможности улучшить свои процессы с их помощью. Они не аналитики, они специалисты по бизнесу. Бизнес-аналитик, в свою очередь, выполняет три функции:
- Он должен уметь анализировать текущее и будущее состояние бизнеса.
- Он должен достаточно хорошо разбираться в технологиях, чтобы понимать, как с их помощью можно трансформировать бизнес-процессы. Речь не только об улучшениях, но и о путях масштабного преобразования процессов.
- Он должен уметь преподнести эти идеи бизнесу, потому что может оказаться, что бизнес вообще не думал о такой возможности, и чтобы он ее увидел, его нужно слегка вдохновить.
Если бизнес-аналитик не знает возможности технологий, то это конечно проблема. Но более распространенная проблема, когда бизнес-аналитику говорят, чтобы он просто делал то, что требует бизнес. Хотите узнать, чего бизнес определенно не хочет? Он не хочет провального проекта, не приведшего к улучшениям. Поэтому задача аналитика — обратиться к корневым требованиям бизнеса и наилучшим образом транслировать их в автоматизацию процессов с использованием имеющихся в его распоряжении технологий.
Если следовать методологии аджайл (который, к слову, почти никогда не реализуется в полном объеме), то, в теории, можно повторить путь с начала — не от того, что бизнес, по его словам, хотел, а от того, что ему на самом деле нужно. Но проблема здесь гораздо глубже, чем просто техническая возможность быстро модифицировать автоматизированные процессы и приложения. Между экспертами предметной области со стороны бизнеса и бизнес-аналитиками должно быть равноправное сотрудничество. Если доминирует сторона бизнеса, то аналитик становится писарем, который просто документирует запросы бизнеса. Если главным является аналитик, то с большой вероятностью будут упущены из виду какие-то важные аспекты бизнес-процесса, которые он не до конца понимает. Здесь важен баланс полномочий.
Проблема буквальной реализации требований бизнеса часто проявляется в виде систем, бетонирующих устаревшие процессы и процедуры. Новая система делает в точности то же, что и ручной процесс, оставляя без внимания возможности его улучшить или автоматизировать с помощью технологий. Куча денег тратится впустую лишь на то, чтобы чуть быстрее раздавать задачи исполнителям. Даже если вы не намерены выбросить прежний опыт и начинать все с чистого листа, вы должны убедиться, что то, что бизнес называет важным, действительно является необходимым и достаточным для выполнения процесса.
Антипаттерны, связанные с ИТ-разработчиками
Многие сложные системы автоматизации процессов ориентированы в большей степени не на бизнес-аналитиков, а на ИТ-разработчиков, которые хуже разбираются в бизнес-требованиях. В такой ситуации может возникать разрыв между между быстро меняющимися условиями ведения бизнеса и внедряемым ИТ-решением.
Чтобы в этом разобраться, нам придется вникнуть в технические особенности системы автоматизации процессов. Как правило, системы автоматизации бизнес-процессов (Business Process Management Suite, BPMS) — отслеживают и хранят текущее состояние каждого экземпляра процесса до его завершения.
Обычно при создании экземпляра процесса в нем фиксируется версия схемы процесса, текущая на данный момент. Если схема процесса меняется, то это отражается только на последующих экземплярах процесса, а уже запущенные продолжают выполняться по прежней схеме. Некоторые системы позволяют переводить уже запущенные экземпляры на новую схему, но в этом есть что-то от хакерства, так что вы вряд ли захотите часто это делать на продуктивной системе.
Существующие системы принятия решений, напротив, как правило не сохраняют состояние: в определенный момент вы обращаетесь к такой системе, передавая некоторые данные, система принимает решение и возвращает результат. Таким образом, если вы внесли изменения в бизнес-правило, то в момент обращения к нему будет применена текущая, самая последняя версия. (Если только у вас нет особых причин, чтобы вызвать старую версию.)
Это позволяет менять бизнес-правила сколь угодно часто, и они будут вступать в силу немедленно. В реальной жизни управление бизнес-правилами часто отдают в руки самих людей бизнеса, чтобы они могли «на лету» изменять определенные параметры — например, менять процент транзакций, направляемых на выборочный контроль, принимая во внимание количество поступающих в единицу времени.
На начальной стадии проектирования необходимо выяснить, какие составляющие бизнес-процесса часто меняются, а какие относительно стабильны. После этого спроектируйте процесс, предусмотрев возможность его изменений в дальнейшем и при этом сохраняя схему процесса прозрачной и понятной бизнесу. Что бы вы не изобразили на схеме, будьте уверены, что первая версия не будет окончательной. Это нормально.
Я многократно убеждалась, что точно так же, как ни один план сражения не выдерживает первого столкновения с врагом, ни один проект системы не выдерживает первого столкновения с конечными пользователями. Научитесь распознавать антипаттерны проектирования, чтобы создавать гибкие системы автоматизации, которые можно итеративно корректировать.
3. Лучшие практики внедрения в проектах автоматизации бизнеса
3.1 Аджайл
Методология аджайл в целом широко используется при разработке ПО, но для проектов автоматизации бизнеса она особенно подходит. Большинство современных средств автоматизации бизнеса позволяют вести разработку от моделей (model-driven), с минимальным программированием (low-code). По крайней мере, с их помощью вы сможете создать и запустить работоспособный прототип приложения, написав минимум программного кода или обойдясь вообще без кодирования. Это не значит, что можно будет полностью обойтись без программного кода — для интеграции или специализированных алгоритмов все же понадобится традиционное кодирование.
Но сочетание разработки от моделей, минимального кодирования и методологии аджайл дает возможность быстро создать рабочую версию приложения и отдать ее на доводку группе бизнес-пользователей. Так реализуется первая лучшая практика внедрения: как можно быстрее запустить в эксплуатацию минимально жизнеспособный продукт, а затем перейти к итерационной разработке. Концепцию минимально жизнеспособного продукта (Minimal Viable Product, MVP) раскрывает рисунок ниже, принадлежащий Хенрику Нибергу (Henrik Nieberg). Вам может также пригодиться его превосходная статья по теме — например, если вам понадобится объяснить коллегам концепции минимально жизнеспособного продукта и итеративного внедрения.
Вы ведь не хотите оказываться в ситуации, когда после месяцев шлифовки системы вы отдаете ее бизнес-пользователям, а они в первый же день не оставляют от нее камня на камне. Вместо этого вы отдаете им систему на ранней стадии разработки. Он все равно не оставят от нее камня на камне, это неизбежно, но вы вложили в эту первую версию не настолько много, чтобы противиться их идеям. Затем вы повторяете цикл, пока не придете к единому мнению о том, как система должна выглядеть и как должна себя вести.
С устаревшей каскадной методологией («водопад») это невозможно. С водопадом у вас уйдет три месяца только на написание технического задания. Плюс время, которое уйдет на согласование с бизнесом — вы ведь хотите, чтобы они решили, чего они хотят, за месяцы до того, как они увидят систему вживую. Затем примерно шесть месяцев на написание и утверждение проектной документации, после чего начнется длительный цикл разработки. И все это ради того, чтобы внедрить систему, которая практически гарантированно не будет соответствовать тому, чего бизнес хочет и тому, что ему действительно нужно. Если проект значительно превысил сроки и бюджет, поинтересуйтесь методологией, и, скорее всего, вы обнаружите водопад.
Водопад прекрасно работает в определенных типах проектов, например, в разработке интеграционного кода, который будет использоваться для подключения к определенным системам по стандартным протоколам. Но там, где люди бизнеса тесно взаимодействуют с программным обеспечением в своей повседневной работе, водопад работает не очень хорошо. Что, конечно, встречается сплошь и рядом. Лучший способ убедить вашу организацию внедрить основанную на аджайл методологию — это продемонстрировать производительность и гибкость средств разработки от моделей с минимальным кодированием. За пару дней создайте первый прототип (не обязательно работоспособный). Покажите его бизнес-пользователям, получите обратную связь. Переделайте и продемонстрируйте новую версию в течение той же недели. В результате пользователи проникнутся идеей итеративной разработки в тесном взаимодействии между бизнесом и ИТ, которая больше всего повышает вероятность успеха проекта.
Такой подход подразумевает тесную связь между командой разработчиков и бизнес-пользователями. Это не значит, что нельзя передать разработку на аутсорсинг или что разработчики не могут находиться в других офисах — это значит, что они должны сотрудничать с бизнесом как единая команда, работать короткими итерациями и быстро реагировать на обратную связь. Если кто-то из команды разработчиков ежедневно не встречается с кем-то из бизнеса, значит они сотрудничают недостаточно тесно. Бизнес должен доверять разработчикам, когда те говорят, что MVP — это лишь этап процесса, а не окончательный продукт.
Слишком много пользователей навсегда остались с версией 1.0 из-за того, что команду разработчиков перебросили на другой проект. Аджайл позволяет покончить с длительными циклами разработки с объемными требованиями и проектной документацией. Ниберг предлагает заменить термин «минимально жизнеспособный продукт» термином «самый ранний пригодный к использованию продукт», который подразумевает, что это не окончательная версия, а первая из многих.
3.2 Готовность к изменениям
Следующая лучшая практика внедрения, о которой я хочу поговорить — быть готовым и уметь менять курс. Речь не о мелких изменениях пользовательского интерфейса, чтобы он больше нравился бизнесу, или новом API для извлечения данных из устаревшей системы. Я говорю о радикальной смене направления или функциональности, когда бизнес увидел первую итерацию и решил пойти по другому пути. Поскольку это первое реальное знакомство бизнеса-пользователей с возможностями автоматизации и средствами с минимальным кодированием, они просто не подозревают, на что те способны. Они изучают первую версию, чешут в затылках и говорят: «послушайте, а нельзя ли полностью автоматизировать эту часть процесса?» или «если мы поменяем вот это, то мы сможем поручить определенные ручные задачи сотрудникам на удаленке?» или «получится ли принимать эти решения автоматически с помощью машинного обучения?» или «можно ли интегрировать эту функциональность в клиентский портал самообслуживания?». Надеюсь, вы уловили идею.
В статье Ниберга есть отличный рисунок, иллюстрирующий этот момент. Что, если вы разрабатываете автомобиль через итерации в виде скейтборда и велосипеда, и тут поняли, что лучше всего было бы сесть на автобус? Относитесь к этому как к радикальному реинжинирингу бизнес-процесса по инициативе бизнеса.
Цели бизнеса обычно сводятся к двум высокоуровневым показателям: чистой выручке и удовлетворенности клиентов. Чтобы достичь этих целей, бизнес будет стремиться к большей автоматизации, более правильным и экономичным процессам, предоставлению клиентов адекватного уровня самообслуживания, а иногда к совершенно новому способу обслуживания клиентов или даже к совершенно другой бизнес-модели. Умный бизнес-аналитик, хорошо разбирающийся в бизнесе и в возможностях автоматизации, предложил бы рассмотреть альтернативныую функциональность еще на ранней стадии.
В противном случае будьте готовы к подобному повороту в тот момент, когда бизнесу будет презентована первая версия.
Обсудить