Как учитывать уровни бизнес процессов
Где требуется учитывать уровень зрелости бизнес процессов
Взаимодействие подразделений, находящихся на различных уровнях зрелости бизнес процессов
Вообще-то, надо помнить про уровни зрелости всегда, когда взаимодействуют бизнес процессы, находящиеся на разных уровнях зрелости.
Цели различных бизнес процессов внутри одной организации всегда в чем-то противоречат друг другу. Центры прибыли и центры затрат влияют на результат компании в противоположных направлениях, и вокруг этого часто возникают разногласия. Инновационные подразделения “тратят” сегодняшние деньги во имя завтрашних, часто спорных возможностей, что тоже приводит к конфликтам внутри компании.
В таких разногласиях всегда более зрелый процесс имеет преимущества. Поэтому в слабо организованных компаниях часто доминирует бухгалтерия, всегда находящаяся между третьим и четвертым уровнями зрелости. И это при том, что бухгалтерия не создает никаких ценностей, которые можно использовать внутри компании. Кстати, поэтому бухгалтера легко нагружают рядовых менеджеров писаниной и формальностями, которые не приносят никакой пользы основной деятельности.
Я описал уже выше, как хорошо организованный процесс бюджетирования губит развитие компании, если основной бизнес процесс не имеет долгосрочного планирования. Для преодоления только одного этого противоречия между краткосрочными финансовыми целями и долгосрочными задачами развития созданы многочисленные методики, вроде Сбалансированной системы показателей и Стратегических карт Нортона и Каплана.
Высшее руководство компании должно хорошо понимать различие в уровнях зрелости подразделений и принимать меры по защите слабо развитых процессов, особенно основного бизнес процесса.
Взаимодействие компаний, находящихся на различных уровнях зрелости.
В сфере услуг не получится полноценного продуктивного взаимодействия между поставщиком услуги и его клиентом, если они находятся на разных уровнях зрелости. Поэтому такое взаимодействие будет приносить убытки обеим сторонам.
Надо относиться к этому утверждению также серьезно, как к законам сохранения энергии и массы. Это объективный закон природы. А законы природы, в отличие от человеческих, нарушить невозможно.
Для качественного взаимодействия клиент и поставщик должны говорить на одном языке
Создание услуги не может быть выполнено без взаимодействия с потребителем – это основное отличие сферы услуг от производства товаров на продажу. Мерой качества услуги, естественно, является удовлетворенность потребителя.
В качестве примера можно привести случай отказа канала связи. Техническим системам свойственно отказывать.
Вариант первый. Во время отказа до провайдера не дозвониться. Клиент остается в неопределенности относительно того, что происходит, принимает ли провайдер меры к исправлению, как долго продлится отказ. Предположим, отказ пролился один час в течение которого клиент постоянно нервничал, т.к. ему требовалось передать партнерам важные данные.
Вариант второй. Во время отказа клиент легко дозвонился до провайдера. Ему объяснили, что проблемой уже занимаются. Через полчаса ему сообщили, что причина выявлена, на устранение потребуется еще три часа. Когда канал заработал, об этом сообщили клиенту. Общее время отказа составило почти половину рабочего дня. Поскольку клиент знал, что связь не будет быстро восстановлена, то он послал к партнерам курьера с данными на носителе. А заодно сообщил им о проблемах связи.
Для клиента второй вариант предоставления услуги связи предпочтительнее, не смотря на значительно более продолжительный отказ. При самом лучшем существе услуги потребитель всегда будет не удовлетворен, если с ним плохо взаимодействовали во время предоставления услуги.
Для качественного взаимодействия клиент и поставщик должны говорить на одном языке, иметь общую систему ценностей. По этой причине, например, стандарт ИТ услуг ITIL прямо запрещает оказывать услуги клиентам, находящимся на уровне развития бизнес процессов, отличном от уровня развития поставщика услуг. А именно, строго запрещается оказывать услуги тем клиентам, которые находятся на более высоком уровне развития. Допускается предоставлять услуги клиентам, находящимся на более низком уровне зрелости, только если при взаимодействии используются специальные процедуры приведения.
Помните шуточный диалог айтишника и секретарши? Это, кстати, пример процедуры приведения.
Девушка звонит в службу поддержки. Девушка – инженеру: “ребята, у меня сломалась полочка для кофе, не выдвигается. Помогите быстрее!” Инженер – девушке: “ну не переживайте так сильно, мы это быстро починим. Мы понимаем, что нельзя работать на компьютере, если полочка не выдвигается. Ну не одной же рукой Вам печатать!” Инженер – системному администратору: “Вася, поменяй секретарю директора CD-ROM. Приоритет высокий.”
При взаимодействии с клиентами необходимо использовать процедуры приведения
Естественно, что это правило действует для всех видов услуг, не только для ИТ обслуживания.
Также важно помнить об уровне зрелости при внедрении программного обеспечения. Есть поговорка, что хаос невозможно автоматизировать, которая говорит о том, что автоматизация возможна только при уровне развития бизнес процесса не ниже третьего (уровень регламентов).
Если браться за автоматизацию не регламентированного бизнес процесса в компании или подразделении, то можно столкнуться с тем, что это подразделение вроде бы хочет сократить трудоемкость текущих операций, но не готово к регламентации своей деятельности. В таком случае очень вероятна неудача во время внедрения.
Кстати, часто бывает, что автоматизация есть, а утвержденных регламентов вроде бы нет. Это особенно характерно для самодеятельной автоматизации “на коленке”. На самом деле это только кажется, что регламентов нет. На самом деле, роль регламентов (правил работы) выполняет программа, автоматизирующая этот бизнес процесс, точнее правила, по которым она построена. Еще в 60-ых Брукс написал, что, если регламента нет, а программа запущена хотя бы на уровне прототипа, то программу надо считать регламентом автоматизированного ею бизнес процесса. В такой ситуации функции отделов стандартизации и регламентации в явном или неявном виде передаются ИТ специалистам.
Возможна и обратная ситуация, когда автоматизацию бизнес процесса берется выполнить компания, находящаяся на более низком уровне зрелости, чем клиент. Если у внедренца нет собственного регламента внедрения, нет регламента постановки задачи на доработку программы, нет регламентов приемки и тестирования, то этот внедренец не в состоянии сделать серьезные доработки программы. Он не сделает гибкой адаптации программы, которая требуется для сбора не финансовых показателей четвертого и выше уровня. Поэтому такой проект закономерно будет неудачен.
Законы природы нарушить невозможно!
В этом разделе
Автор статьи
