Проблемы, которые могут привести к описанному выше развитию событий, следующие:
1. Функциональные требования формулируют пользователи
2. Функциональные требования к модификации подменяются описанием модификации
3. Руководство заказчика отказывается от скрупулезной оценки экономического эффекта от каждой модификации.
Это далеко не весь перечень проблем, но можно уверенно сказать, что «по совокупности» они с большой вероятностью сведут в «могилу» сотрудничество между любыми заказчиками и исполнителями, как бы хорошо они ни были настроены друг к другу изначально.
Каковы причины и последствия перечисленных проблем?
Ошибка первая, она же основная: требования формулируются пользователем
Общеизвестно, что формулирование требований к автоматизации процесса подразумевает четкое представление о задачах, стоящих перед процессом с точки зрения бизнеса, понимание границ процесса, способность дать детальную оценку отдачи от инвестиций в автоматизацию. Наиболее вероятно, что подобными знаниями обладают сотрудники, представляющие себе принципы функционирования процесса, и, одновременно, способные мыслить в категориях оценки экономической эффективности бизнес-процессов. Как правило, это достаточно высококвалифицированные управленцы, сильно загруженные текущей работой.
В то же время, в любой компании есть участники процесса (пользователи), которые уверены, что они точно знают, как необходимо улучшить работу системы: какие из участков неохваченных автоматизацией бизнес-процессов следует автоматизировать, какие заложенные в системе алгоритмы следует изменить. Как правило, эти сотрудники аккуратны, исполнительны, хорошо выполняют свои обязанности и уважаемы руководством за то, что они на своем месте думают о том, что надо сделать для того, чтобы организация работала лучше.
Когда заходит речь о развитии системы, у руководства компании-заказчика появляется соблазн предложить пользователям заняться реализацией своих предложений. Более того, заказчиком может быть принято сознательное решение о том, что выделять время управленца для формулировки требований к автоматизации бизнес-процесса неоправданно и даже вредно: ведь есть пользователь, который «лучше знает», как надо сделать. В результате курировать работу по автоматизации бизнес-процесса поручается непосредственному участнику этого процесса — это первая и потенциально очень дорогая ошибка.
Обоснование ошибочности данного решения можно сформулировать следующим образом.
При постановке задачи пользователь, как непосредственный участник процесса, решает одну задачу: автоматизировать как можно больший участок работы. При этом он обладает ресурсом, который, как правило, подсознательно воспринимается как бесплатный: даже само понятие оценки экономической целесообразности, за редкими исключениями, не входит в круг его компетенций. Наиболее разумная стратегия для такого участника проекта — бесконечно дорабатывать модификацию, чтобы автоматизировать как можно большее количество частных случаев.
Возникающую в результате такого подхода избыточность требований к модификации можно продемонстрировать следующим образом. Предположим, что при описании вариативности реализаций некоторого автоматизируемого бизнес-процесса работает упрощенное правило Парето 20/80 (используем правило Парето просто как пример закономерности, которую принято применять для описания практически любых несложных экономических закономерностей). В этом случае 20% вариантов реализации (частных случаев) бизнес-процесса составляют 80% всех случаев реализации. 36% вариантов реализации — 96% всех случаев. 49% вариантов реализации — 99% всех случаев.
Представленные цифры наталкивают на мысль, что с точки зрения того, кто платит за модификацию, при определенных условиях может иметь смысл ограничиться автоматизацией, допустим, 36% вариантов реализации. Таким образом, 96% всех реализаций система будет обрабатывать автоматически, оставшиеся же 4% реализации может быть целесообразным оставить для полуавтоматической обработки (по каждому из них пользователь должен будет принимать индивидуальное решение).
Если абсолютный объем трудозатрат на полуавтоматическую обработку каждого случая значителен, или же цена некорректной обработки уникальных случаев велика, может оказаться экономически обоснованным разработать модификацию, оставляющую меньшую долю случаев для полуавтоматической обработки. Но в любом случае тот, кто оплачивает модификацию, рассматривает ее целесообразность с точки зрения экономического эффекта: сокращения издержек или роста доходов. Очевидно, что руководство компании не ставит себе цель облегчить жизнь пользователю. Его задача — обеспечить себе достаточно высокую отдачу от инвестиций в модификации.
Пользователь же, как показывает практика, в большинстве случаев уверен, что автоматизация 50% частных случаев — несуразно малый результат. Тот факт, что эти 50% закрывают 99% всех реализаций процесса, его вряд ли впечатлит: ведь он видит, что оставшиеся 50% частных случаев, как бы редко они не случались, придется разрешать «руками». Поэтому пользователь готов долго и вдумчиво прорабатывать частные случаи, бесконечно расширяя требования к системе.
Ошибка вторая, отягчающая: согласовываем «как» вместо «зачем»
Описанная выше проблема может многократно усугубиться, если консультанты допустят подмену понятий, и вместо формирования функциональных требований к модификации фактически ввязываются в формирование собственно описания модификации. Если требования формирует пользователь, для исполнителя допустить такую ошибку проще, чем может показаться на первый взгляд: из-за описанного выше специфического взгляда на проблему пользователь склонен скорее формировать свое видение «правильных» алгоритмов работы модификации, чем искать четкие ответы на вопрос о том, зачем эта модификация нужна.
Однако исполнитель должен понимать, что десятки часов, потраченные на описание хитросплетений замысловатых алгоритмов, предусматривающих все, что только может случиться, с большой вероятностью, окажутся для заказчика деньгами, выброшенными на ветер.
Исключения
Следует оговориться, что в практике встречаются исключения: пользователи могут очень разумно описывать желаемое устройство модификации, разумно подходить к вопросу о необходимости автоматизации частных случаев и корректно оценивать экономическую эффективность модификации. Можно предположить, что адекватность пользователя, как представителя заказчика, определяется, в первую очередь, тем, насколько близко данный сотрудник стоит к центру принятия финансовых решений (чем ближе, тем лучше), уровнем его образования и профессиональным опытом. Например, финансовый директор или собственник практически не допускают описанных выше ошибкам.
Описанные проблемы не относятся к «пользователям-исключениям».
Если две ошибки допущены: как искать выход
Если компания-исполнитель допустила такое развитие событий, у нее есть, по большому счету, два выхода.
Выход первый: смириться и стараться помочь пользователю формализовать, описать и реализовать его предложения. Это может оказаться очень выгодно в краткосрочной перспективе, особенно в случае, если заказчик оплачивает работы по принципу «time & material». Однако мы все понимаем, что это, во-первых, просто непорядочно со стороны исполнителя, а во-вторых, это неоправданно в долгосрочной перспективе: рано или поздно встанет вопрос, каким образом автоматизация малозначительного бизнес-процесса обошлась заказчику в сумму, превосходящую всякие представления не только об экономической целесообразности, но и об элементарном здравом смысле. Ведь в итоге, как всем известно, честным быть выгодно.
Выход второй: взять на себя работу по выявлению и сегментированию требований к модификации на основании пожеланий пользователя, сформировать для каждого функционального требования отдельный бюджет, оценить экономическую целесообразность каждого требования, указать свои рекомендации и представить итоговые материалы на согласование руководству компании-заказчика. С одной стороны, это потребует определенных трудозатрат со стороны исполнителя, а значит — расходов со стороны заказчика. С другой стороны — расходы на выделение функциональных требований, анализ экономической целесообразности модификаций и на формирование соответствующей документации не идут ни в какое сравнение с теми убытками, которые в противном случае может понести заказчик.
Если эта работа добросовестно выполнена исполнителем, у заказчика есть возможность разобраться в происхождении несоразмерных сумм, отсечь лишнее, правильно расставить акценты.
Ошибка третья, контрольная: заказчик платит не глядя
Самая тяжелая ошибка, которую может допустить руководство заказчика на этом этапе — в силу каких-то причин уклониться от скрупулезной оценки экономического эффекта от проектируемой модификации.
Подобные действия могут быть вызваны широким кругом самых разных причин: начиная с «доверия» по отношению к пользователю (причем пользователь вполне может заслуживать доверия при выполнении своих прямых обязанностей, как правило, это ответственные и добросовестные сотрудники), заканчивая банальной ленью, ведь заниматься оценкой целесообразности модификаций зачастую занудное занятие.
Если заказчик отказался от оценки экономической целесообразности модификаций, остается надеяться только на то, что наш пользователь — счастливое исключение. Такое тоже бывает, но рассчитывать на везение как на системный способ решения проблем все же не стоит.
Все ошибки допущены. Что делать
В заключение хотелось бы описать рекомендации, отвечающие на вопрос «Что делать?», для участников тех проектов, которые уже увязли в подобных проблемах. Поскольку последовательное описание рекомендаций потребовало бы значительного объема, ограничимся краткими тезисами.
Для начала рекомендуется последовать правилу, общему для всех конфликтов: поговорить «об этом» с партнером. В данном случае требуется тактичный, но искренний разговор ключевого представителя заказчика с вызывающим у него наибольшее доверие представителем компании-исполнителя. Необходимо понять, какие из перечисленных выше проблем реально существуют. Если обнаружится, что заказчик четко видит проблему, а исполнитель настаивает на том, что все нормально, это может указывать на то, что исполнитель не ориентирован на долгосрочное сотрудничество. В этом случае лучше сменить исполнителя.
После того, как проблемы обозначены, необходимо принять два принципиальных решения.
Во-первых, принять совместное решение не повторять ошибок при разработке новых модификаций (если уровень доверия еще позволяет говорить о разработке новых модификаций) и последовательно воплощать это решение в жизнь: выделять квалифицированных исполнителей для формулировки функциональных требований, добросовестно проводить оценку экономической целесообразности требований. Исполнитель сможет помочь в формулировании требований, предоставлять информацию о планируемых затратах в разбивке по требованиям (чтобы было понятно, сколько стоит реализация отдельных требований), в оценке экономической целесообразности. Если выяснится, что компания-исполнитель не в состоянии этого сделать, лучше сменить партнера.
Во-вторых, принять решение о судьбе модификаций находящихся в реализации: те из них, за реализацию которых исполнитель сможет поручиться по срокам и оставшимся затратам, можно попытаться довести до конца.
Те же модификации, объем работ по которым велик, а затраты на завершение очевидно огромны, но не предсказуемы, возможно следует обработать заново по нормальному алгоритму: сформулировать, какова цель модификации, описать функциональные требования, принять решения о том, что стоит автоматизировать, что не стоит. Квалифицированный исполнитель сможет с наименьшими трудозатратами интегрировать часть предыдущих наработок в новую функциональность, хотя заказчику и придется смириться с тем, что большая часть затрат, понесенных ранее на реализацию данной модификации, безвозвратно потеряна.
Из сказанного выше следует, что при приемлемом уровне квалификации исполнителя вывести из штопора отношения, подорванные потерей доверия, вполне возможно, причем это может оказаться проще и дешевле, чем менять партнера. Главное — правильно определить корень проблемы. Тогда развитие системы вновь станет для заказчика тем, чем оно должно быть: мощным инструментом развития собственного бизнеса.
Комментариев нет:
Отправить комментарий