Бизнес зиждется на верном клиенте, который непременно возвращается вновь и приводит с собой друга. (Эдвардс Деминг)

Причины типичных ошибок при постановке СМК, их профилактика и преодоление

Елена Маркушина специалист международного класса по управлению изменениями

Война и маневры

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

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

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

 знаний по психологии;

 способностей к прогнозированию;

 профессионального интереса как двигателя мотивации;

 портфельного типа карьеры и прочее, чему должно посветить материал особый.

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

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

Помним и верим

Наивно полагать, что с уходом из компании сотрудников, принимавших некогда участие в проекте, произойдет очищение корпоративной памяти. Только недавно стали появляться работы, проливающие свет на опасные и многоликие грани, корпоративной культуры. Слава Богу, а то последняя фишка в данном вопросе на стороне тех, кто считает, что корпоративная культура - это миф (Маркус Бакингем - один из лидеров Galiup Media).

Некоторые не столько крайние коллеги из консалтинговой и IT-внедренческой среды отмечают, что при первом знакомстве с компанией они чувствуют интуитивно некое общее настроение, которое определяет отношение сотрудников к визиту ("то ли война, то ли эхо прошедшей войны"). Что именно, не разбираются, предоставляя немой вопрос самому себе.

"Если я этого не понял - значит этого нет" - заявил некий консультант, совершенно убежденный в своем интеллектуальном превосходстве над Клиентами. Ну так успехов, господа в таком непростом деле, как создание ИНТЕГРИРОВАННОЙ СИСТЕМЫ МЕНЕДЖМЕНТА.

Для компаний - симбиозов княжеств удельных - этот вопрос не праздный. И во многих случаях подозрительно понятный. Ничего ломать или менять не нужно "надо просто, чтобы они стали работать слаженно". Если заставить дружить домами приказом по фирме нельзя, то:

 можно поступить по-фордовски, то есть поставить на Президента.

"Долгое время компания функционировала как система независимых <княжеств>, объединенных под флагом региональной или функционалъной экспертизы", - говорит Нассер <Как правило, княжества Ford не враждуют друг с другом, хотя и такое случается, но их абсолютно не волнует, что происходит с компанией в целом>. Он вспоминает собрание двухлетней давности, в котором принимали участие 200 руководителей высшего звена. <Они знали все о работе своих собственных подразделений, но ни один не мог сказать, каковы активы компании, ни один не мог указать ее экономическую добавленную стоимостъ или соотношение Р/Е>.

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

 можно рассуждать иначе. "Надо купить "интегрирующую" систему и подороже. Чем дороже, тем лучше, тем скорее сгорят мосты и взрастет решимость довести дело до конца". Заблуждение, на мой взгляд, серьезное.

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

 прежде, чем предложить свой вариант, поясню мотивы.

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

Grow gradually (расти постепенно)

Методы, которые будут предложены ниже, по сути являются гомеопатическими. То есть приучают компанию есть слона по частям. Я называю их дегрисионными (от by degrees - постепенно добавляя градус, накал, масштабность и глубину событий).

Начнем сначала, которое, как известно, зиждиться на трех китах: люди, процессы, информационные технологии.

Все мы человеки

Люди - это первое и главное. Гуманитарная сторона дела очень важна и в психологическом и в организационном смысле.

В стремлении к интеграции часто начинают стирать границы, которые не только стирать нельзя, но нужно укреплять, предавая новую форму. Совершенно оправданные и, не побоюсь этого слова, полезные разногласия между функциональными менеджерами, например финансистами (<крохоборами>) и маркетологами (<транжирами>), зачастую воспринимается руководителем как препятствие на пути интеграционного процесса. Считается, что их нужно прежде помирить, добиться единения порывов, вследствие чего задача интеграции решится сама собою процентов на 80%. Останется автоматизировать их коммуникации и централизовать отчетность.

Под лозунгом <пусть они, наконец, договорятся>, директор начинает миротворческие операции, а менеджер по персоналу ему в этом <помогает>. Вместо того, чтобы объяснить руководителю, что <работать в команде> и <думать одинаково> ни одно и то же, что нельзя совмещать несовместимое, они вывозят коллективы за город, объединяют отделы, создают перекрёстные команды (без предварительной подготовки). Все из самых лучших побуждений.

Помочь здесь сможет только практический курс для руководителя

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

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

Возвращаясь в оптимистическое русло, заметим, что многие компании проходят осмысление всех граней своего корпоративного характера в рамках проекта по организационному проектированию. Финалом этого этапа становится, во-первых, появление свода законов копании (от организационной структуры и <Положения о Персонале>, до должностных инструкций и органиаграммы). Во-вторых, перестройка компании (объединение -разделение).

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

Если к этому времени мы располагаем реальным перечнем персонажей, готовых взаимодействовать, необходимо выявить, проанализировать, перепроектировать и закрепить в регламентах процессы, которые обеспечат наибольшую эффективность работы компании на сегодняшний день (и на некоторую часть от завтрашнего). Есть подозрение, что рутинные, повторяющиеся операции уже сегодня помогают выполнять компьютеры. То есть имеется локальная компьютеризация и учет небухгалтерской информации по отделам.

Если это так, то самое время вспомнить, что CRM идеология - это нечто большее, чем только <Управление взаимоотношениями с клиентами>. Процессный подход к выстраиванию управления предполагает, что каждый владелец процесса (суть ключевой сотрудник) является потребителем результатов труда владельца процесса N-1. В управленческом смысле, все менеджеры и специалисты являются Клиентами друг друга.

Остается найти опору, которая поможет дальнейшему движению вперед. По моему мнению, таким основанием/опорой может стать традиционно-трепетное отношение всех компаний всех возрастов и отраслей к простому русскому слову БАЗА. Коллективный разум (точно также, как и индивидуальный) наделяет это слово самой позитивной семантикой. <Поставить CRM-систему> - это понятно единицам. <Создать БАЗУ> - это понятно всем. Но только рядом со словом <база> мы припишем мелким шрифтом слово <знаний> и разъясним смысл сочетания <База Знаний> каждому функциональному руководителю так, как это и должно пониматься финансистом, производственником, директором по продажам.

Так от гуманитарного аспекта, через наведение порядка и выстраивание процессов мы подошли к автоматизации последних. Казалось бы, все готово для появления, скажем, пакета Aris. Ничего подобного. Если компания проходила вышеназванное становление на витке N 1 спирали развития, то она ни каким образом не может быть готова к внедрению инструментов, показанных на этапе N 2 или 3 (браки с 14 лет еще можно понять, но с 12-ти...).

Однако, сетования интеграторов на то, что у Клиентов <верхи не хотят, низы не могут> и наоборот, не прекращаются. Не Клиенты упорно не хотят становиться готовыми. Это интеграторы забывают, что исторический процесс взросления компании происходит не только в пространстве, но и во времени. Как говорится: сколько беременных женщин в одной комнате не собери, раньше чем через 9 месяцев они не родят.

Оно еще и летает

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

Прототип должен:

 стоить столь мало, чтобы крохоборы отдали эту сумму с улыбкой (<что на такие деньги можно навоять?>);

 возникнуть в кротчайшие сроки (пока потребность в подобном проекте на повестке дня);

 рождаясь, не отвлекать людей от их основной деятельности, через пару месяцев стать приятной неожиданностью;

 закрыть болевые точки компании особенно в плане ответа на вопрос <что у нас происходит, происходило и планируется>;

 иметь интуитивно понятный (до примитивного) интерфейс, чтобы трудности при его внедрении в будущем нельзя было списать на понятийный барьер;

 визуализировать желанную Базу Данных, которая может быть проиндексирована всеми возможными в компании способами;

 ненавязчиво побуждать менеджеров к коммуникациям и объединению усилий (теперь дружим не против кого-то, а на благо общего дела, то есть Базы);

 запустить механизм нарастания аппетита во время еды (то есть вызвать интерес к программным решениям более высокого уровня);

 облегчить в будущем общение компании с поставщиками п/о. Время обсуждения ТЗ от нескольких месяцев сокращается до 1 рабочего дня (<хочу также, но это, плюс это, плюс то>);

 порождать отчеты, как текстовые, так и графические, что позволит вести новые числовые и качественные критерии оценки деятельности;

 сформировать у руководства устойчиво позитивное и трезвое отношение к интеграционным проектам в будущем.

Одним словом, выгоды от Прототипа должны безоговорочно превышать вложения в его создание. Эти затраты складываются из стоимости услуг постановщика задачи (создание ТЗ и контроль за ходом проекта), программиста, менеджера по насыщению базы и отладке программы.

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

Если вы думаете, что создание прототипа (компьютерной программы) автоматически определяет состав рабочей группы под руководством ведущего программиста, то это опасное заблуждение. Тот, кто разрабатывал процессы, вел проект по оргпроектированию, понимает, как в реальности система будет работать потом, каковы ожидания руководства (какие отчеты нужны), тот, кто имеет опыт разработки программных продуктов и должен этим заниматься.

Вот потому у нас такое дело - не повсеместная практика, потому как решение подобных задач - часть миссии консалтера. А мы еще до сих пор не потрудились разобраться, кто это такие и обзываем их консультантами. В начале статьи мы говорили о менеджере среднего звена и его роли Агента Изменений. Консалтер (представитель армии системщиков) совмещает в себе эти роли. Он также может выступить внешним куратором подобного проекта.

Создание прототипа CRM-системы девелопмента

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

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

Под лэнд-девелопментом компания понимает то же, что и её зарубежные коллеги: инвестиционно-строительную деятельность, направленную на создание на пустом (не облагороженном человеком) месте объектов недвижимости, коренным образом влияя на повышение инвестиционной привлекательности района.

Под просто девелопментом компания понимает комплекс мероприятий, предшествующий строительству и предполагающий диктат маркетинга. Именно он определяет, где и что строить, из чего, по какой цене продавать построенное и как развивать инфраструктуру.

К девелоперскому блоку относятся также этапы:

 получение разрешений на строительство;

 прохождение всех необходимых регламентирующих инстанций;

 согласование проекта;

 создание инвестиционного бизнес-плана.

Нетрудно заметить, что конечного потребителя (горожанина, арендатора и т.д.) здесь нет. Результат труда Девелопера востребуется с одной стороны Инвестором, а с другой Генеральным Подрядчиком. Кроме того, в ряде случаев Девелопер может выполнять функции Заказчика.

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

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

Вот каковым было начало в данном конкретном случае.

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

Забудьте о домах и бизнес-центрах. Пусть это будут другие проекты / продукты / модели.

Нужно было понять: какие включать, а какие нет; дать общую справочную и техническую информацию о каждом, указать на каком этапе находятся работы.

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

Подобная табличка должна выпускаться нажатием одной кнопки (максимум трех). И порождать её должна База Знаний о наших текущих проектах и работах. Но господа невольно сделали большую работу. Они определили вид документа (отчета), который для их задач принятия удовлетворителен. <Хотите такой же, но без совещаний?>.

Кроме того, коллективная память иногда удивляет провалами и невозможно добиться, что было тогда-то и в какой связи появилось то или это. Не надо помнить, разгрузите память, пусть помнит База. А руководитель опять же нажатием одной кнопки может получить доступ к паспорту Клиента / объекта / продукта и к его истории.

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

Круговые и блочные диаграммы, наглядно показывают, в каких долях распределены усилия компании, где она более успешна и т.д.

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

Снимутся многие взаимные претензии, так как <картина чего и сколько>, а также <кто виноват> будет написана бесстрастным компьютером, с которым спорить бесполезно.

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

И еще один результат станет неожиданным сюрпризом для топ-менежеров. Прототип предоставит им артефакты в пользу утверждения Деминга, что 98% успеха в деле повышения качества управления фирмой приходится на долю топ-менеджеров, в то время, как на линейный персонал всего 2%.

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

Сентябрь 2003 г.