Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Вам нужны руки или мозги?

Вопрос вообще-то адресован потенциальным спонсорам проектов BPM, т.е. первым лицам и/или собственникам. Правда на ответ с их стороны рассчитывать особо не приходится, так как подозреваю, что среди посетителей моего блога их почти что нет.

А возник он потому, что я не в первый встречаю компанию-заказчика или потенциального заказчика, во главе которой стоит молодой, амбициозный, энергичный и - что самое главное - грамотный руководитель. Казалось бы, здорово! Действительно радует, что не приходится тратить время на рассказ о том, что такое бизнес-процессы и BPM - человек уже подготовлен, в том числе благодаря нашему bpms.ru.

Но потом сталкиваешься с проблемой: руководители такого типа склонны не ставить задачу, а диктовать решение. Мы ожидаем, что нас позвали разобраться с проблемой и предложить решение, а оказывается, на нас смотрят как на “автоматизаторов”.

Что хотелось бы и что приходится слышать от заказчика:

Хотелось бы услышать Приходится слышать
У нас плохо регламентировано взаимодействие служб на этапе пресэйла. В результате мы то опаздываем с коммерческим предложением, то работаем в убыток. Интересы отдела продаж, инжиниринга и производства объективно противоречат друг другу, и это негативно отражается на командном духе компании. Я, как первое лицо, могу и должен помочь в продвижении важных сделок, но всюду успеть я не могу, а четкого понимания где и когда надо вмешиваться, у меня нет. Нам нужна система документооборота для контроля заключения договоров.
Нам нужна инфраструктура, которая позволит выпускать новый страховой продукт за два месяца вместо нынешних шести - это даст нам возможность постоянно быть на полкорпуса впереди конкурентов и существенно увеличить долю рынка. Вы можете разработать для нас программу для страхования рисков при покупке недвижимости?
Я хочу до минимума снизить необходимость в телефонном общении с менеджером для клиентов нашего автосервиса - чтобы они могли через интернет записаться на техническое обслуживание, отследить состояние заказа и отдельных работ, получить электронный счет и оплатить его пластиковой картой. Мы рассчитываем таким образом выделиться на фоне конкурентом и привлечь к себе наиболее “продвинутых” и платежеспособных клиентов. Нам нужна программа с веб-интерфейсом для менеджеров, принимающих заказы на техническое обслуживание.
В соответствии с Теорией ограничений, производительность нашей компании определяется производительностью узкого места, которым является производственная линия. Соответственно, мы должны создать систему планирования и диспетчеризации, которая обеспечит максимальную загрузку линии и исключит срывы поставок. Для этого необходимо реализовать сочетание алгоритмов MRP-II и APS. Сделайте нам интеграцию между учетной системой и программой, рассчитывающей производственный график, и импорт в нее понедельных планов из Excel.

Получается, заказчику нужны не наши мозги, а наши руки?

Причем те же самые руководители вроде соглашаются, что между бизнесом и ИТ существует разрыв, что это плохо, что его надо сокращать - а это как раз один из ключевых тезисов BPM (”bridging the gap”, или, как стали писать в последнее время, “closing the gap”). Но, господа, сокращать его надо с обеих сторон! Не только ИТ выходить за пределы своих “железок”, подниматься на уровень бизнес-целей и бизнес-процессов, но и бизнесу преодолевать свою кастовую замкнутость и переставать смотреть на любого, кто разбирается в корпоративных системах, как на “программиста”, который автоматизирует что скажут.

Руководитель, считающий, что ему заведомо нечего ждать от консультанта, поскольку тот никогда не руководил такой компанией, как его (причем желательно, в точности такой же, как его). Банкир, считающийся только с мнениями других банкиров и относящийся к ИТ, как к обслуге. Собственник бизнеса, которому обратиться к консультанту не легче, чем Тони Сопрано к психоаналитику: не дай бог партнеры по бизнесу или конкуренты узнают - сочтут за слабость.

Дело ваше, господа, но это неправильный взгляд на роль специалиста и тупиковый путь. (Да, встречаются некомпетентные и недобросовестные консультанты, но это отдельный разговор.) Окончательное решение (но и ответственность за него!), безусловно, должно оставаться за вами. Но зачастую вы ведь просто спускаете задачи вниз на исполнение и не делитесь с бизнес-аналитиками и консультантами своими проблемами, не обсуждаете с ними свои идеи, не готовы выслушивать их мнения и рассматривать их предложения.

Вы спрашиваете, что такое правильный взгляд на роль специалиста? Возьмем аналогию: я собираюсь строить дом. У меня есть концепция - я знаю каким он должен быть с точки зрения функциональной. Я твердо знаю в каком он должен быть стиле (а-ля Миконос, если кому интересно). У меня есть какие-то идеи по планировке, по декору. Я способен самостоятельно сделать чертеж в Archicad. Но я не иду дальше эскизов, цель которых исключительно в том, чтобы донести свои идеи до архитектора.

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

Я не всегда соглашаюсь с тем, что предлагает архитектор. Иногда он не соглашается с с моим выбором. Но всегда и безусловно я внимательно, с подчеркнутым уважением его выслушаю. А если заставлю принять мою точку зрения, то обязательно подчеркну, что осознаю риск и принимаю всю ответственность за данное конкретное решение на себя. Потому что если я не буду этого делать, он мысленно поставит на мне крест, как на бестолковом клиенте. А это мне, как заказчику, нужно меньше всего.

Возвращаясь к теме BPM: тут абсолютно то же самое! Тут тоже “творческого человека каждый обидеть может”. Тут тоже не спорить с заказчиком, когда ты с ним не согласен, означает оказывать ему медвежью услугу. Опереться можно только на то, что сопротивляется! Если передавить, консультант мысленно махнет на вас рукой и будет работать по принципу “чего изволите”. Положим, я лично скорее выйду из проекта, но многие ли могут себе это позволить?

Причем BPM в этом смысле - коварная вещь. Для сравнения, если речь идет о внедрении ERP, то поставщику или консультанту легче заставить заказчика принять свою точку зрения: “Это система может - это не может, а если хотите переделать, то это будет стоить столько-то. Мы лучше знаем как внедрять нашу систему, и наша методология внедрения отработана на сотнях компаний по всему миру.” В случае же BPM речь идет о бескомпромиссном учете специфики бизнеса, и у заказчика возникает иллюзия, что тут все понятно - в конце концов, что он, не знает свой бизнес? Значит, он может диктовать что и как надо делать.

Нет, бизнес он, конечно, знает. Но в “современных технологиях строительства” разбирается слабо. Вот например, на прошлой неделе потенциальный заказчик требовал от нас предложения на разработку BPM-системы под ключ. Подчеркну: это активный, умный, грамотный человек. Но он даже не подозревает, что есть какие-то другие способы разработки и внедрения, кроме “под ключ”, т.е. старого доброго “водопада”. Пришлось “на пальцах” объяснять ему, что существует более прогрессивная методология разработки под названием agile и что проект, выполняемый согласно жестко утвержденным требованиям - это что угодно, но не BPM. И что, пойдя по этому пути, он гарантированно придет туда же, куда пришли все остальные до него, то есть к автоматизации не до конца понятых или заведомо неоптимальных бизнес-процессов. Он нас выслушал, но с заметным недоверием. Слово “agile” записал - посмотрим, что в итоге выберет.

Руководителю может не хватить отстраненности и системности. Он упирается в один бизнес-процесс, который сегодня доставляет ему основные неприятности. Я совсем не сторонник многомесячных обследований и тотального разбора бизнес-процессов на шесть уровней вглубь, приводящему к “аналитическому параличу”. Но не потратить хотя бы неделю на эскизное документирование цепочки создания ценностей компании и на выявление потенциала улучшения в ней (gap analisys) значит впадать в другую крайность. Бывает, корень проблемы не в данном процессе, а в том, который его запускает или наоборот, в том, который он запускает.

На близкую тему у нас состоялся обмен мнениями на блоге Gary Comeford: Who’s running your process project - The Chicken or the Pig? Гэри пишет, что без вовлеченности высшего руководства проект BPM состояться не может.  С этим не поспоришь. Далее, он различает 1) вовлеченность, когда высший руководитель выступает в роли классического спонсора - принимает решение, выделяет бюджет, принимает результаты, и 2) активное участие - когда высший руководитель сфокусирован на проекте и воспринимает его как личный. По мнению Гэри, в жизни чаще встречается первый вариант, но второй предпочтительнее. Возможно - но только не тогда, когда вы имеете дело с руководителем, склонным вместо постановки задачи диктовать решение для исполнения. Если такой руководитель вовлечен в качестве спонсора, то у проекта есть шансы, а если более активно, то боюсь, что нет. Гэри в связи с этим сделал ценное замечание: некоторые путают ответственность с компетенцией.

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

Проблема завоевания доверия первого лица, дилемма - спорить с ним или делать как он скажет - известны любому бизнес-консультанту. В связи с этим, о каком именно консалтинге мы говорим? Я бы выделил три уровня:

  1. ИТ-консалтинг. Функция консультанта - понять, что говорит бизнес-заказчик на своем языке, и пересказать это с минимальными искажениями разработчику уже на языке ИТ. Понимание языка бизнеса здесь обычно минимальное, его можно сравнить с тем, как в резюме пишут “иностранные языки - английский, читаю со словарем”.
  2. Управленческий консалтинг. Консультант, работающий на этом уровне, обязан уже не только понимать, но и разговаривать с бизнесом на его языке - высказывать какие-то идеи, давать предложения. Это уже соответствует “английский - свободно”. Но эти специалисты обычно “плавают” в ИТ, и поэтому для программиста они почти такие же “иностранцы”, что и бизнеса-пользователи.
  3. Бизнес-консалтинг. Предполагает способность на равных разговаривать с владельцами и первыми лицами, уметь добираться до корня проблем и предлагать инновационные решения. Языком бизнеса бизнес-консультант владеет как родным, но ожидать знания языка ИТ от него можно только в виде исключения - как исключением является Набоков, получивший признание как писатель, писавший и на русском, и на английском языках.

Поле деятельности бизнес-аналитика от ИТ-службы - первый уровень. См. на эту тему статью: Paul Harmon, ”Are You a Business Analyst?“, русский перевод.

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

Вот почему обращаться к консультанту по BPM как к “автоматизатору” (с задачами первого уровня) значит использовать его потенциал только наполовину.

На втором уровне консультант отвечает на вопрос “как делать”, на третьем - “что делать”. (По-английски это звучит лучше: “do things right” vs. “do the right things”.) Требовать от консультанта по BPM профессионализма на третьем уровне было бы слишком, но воспринимать идущую с него информацию он должен уметь. Надо только, чтобы бизнес такой информацией делился, то есть чтобы бизнес нуждался не только в наших руках, но и в мозгах.

07.12.09 | Статьи | , , ,    

Комментарии (2)

  1. Julia Wagner 09.12.09 14:37

    ну так его (руководителя) можно понять. Ему кажется, что он предлагает решение вместо проблемы. И наверное очень этим гордится.

    And I can understand him (I mean the head). He thinks that he offers a solution instead of the problem. And probably he proud of this.

  2. Кузин Сергей 28.12.09 12:28

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

А что вы думаете?

Captcha

Copyright © 2008-2016 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии