Несмотря на то, что я начинал, как программист, сегодня я буду выступать в немного нетипичной для себя роли, поскольку мы с вами будем говорить о внедрении проекта с точки зрения его заказчиков, тех, для кого все это делается, а не с точки зрения исполнителей, тех, кто все это делает, внедряет.
Почему так получилось? В какой-то момент, во время очередного кризиса, меня, как руководителя отдела, вызвали владельцы предприятия. И они задали мне такой интересный вопрос: «Расскажите, пожалуйста, что вы можете предложить бизнесу, и как вы видите наше с вами дальнейшее сотрудничество». Говоря простым языком, «зачем вы нам нужны?»
Я начал было рассказывать, что без меня все дело вообще рухнет, пользователи работать не смогут, я поддерживаю регламентированную отчетность, ставлю обновления, обрабатываю кучу заявок пользователей и т.д. Работы невпроворот, и мне бы наоборот, еще пару сотрудников в помощь, и еще зарплату поднять, а вы тут такие вопросы задаете.
На что мне один из вопрошающих ответил: «Хорошо, представьте, что с завтрашнего дня вы станете работать в два раза лучше (прямо пахать начнете), или, наоборот, в два раза хуже (начнете приходить к обеду, уходить пораньше и т.д.). Теперь подумайте,что при этом изменится для меня с точки зрения инвестора, вкладывающего деньги? Замечу ли я изменения в вашем графике? Понятно, что пользователи, скорее всего, начнут жаловаться, и директору, наверное, станет хуже. Но для меня, для хозяина, что-нибудь изменится?»
Честно говоря, на этот вопрос я ему ответить не смог. И у меня закралось подозрение, что видимо, действительно, ничего особо не изменится. Из чего вытекал такой интересный вывод, что, оказывается, не так уж я и нужен. Конечно, все то, что я делаю для своего руководства, вплоть до директора, – это, возможно, хорошо. Но с точки зрения владельца самого бизнеса – все мои усилия не так уж и важны.
Это было уже достаточно давно, и с тех пор я довольно много размышлял о том, что такое эффективность. Ведь действительно, есть очень много хороших программистов, которые успешно решают поставленные им задачи, но их труд при этом никто не ценит. И проблема, на мой взгляд, не в них, а в том, какую эффективность решение этих задач дает бизнесу. Потому что люди очень часто делают что-то хорошо, но это не то, что действительно нужно. Они прекрасно копают яму, красивую, ровную, но не в том месте. Поэтому не так уж важно, насколько красивая и ровная у них получается яма.
Соответственно, об этом я и хотел сегодня рассказать.
Зачем нужна автоматизация?
Автоматизация первого уровня – «так принято»
Попробуем ответить на вопрос – зачем нужна автоматизация?
Для автоматизации бизнеса может быть много причин – у каждого своя. Все мы уникальны, у каждого предприятие такое, которого ни у кого больше нет, и никогда не будет.
Тем не менее, статистически можно выделить наиболее часто встречающиеся причины автоматизации. И, как ни странно, самой распространенной из них будет: «У других есть, и я тоже хочу». Сюда же относится вариант «так принято».
Итак, я решил организовать свое предприятие – например, я хочу продавать полиэтиленовые мешки. Что значит «организовать предприятие»?
- Это значит, что мне нужен бухгалтер,
- Мне нужна 1С:Бухгалтерия – как минимум.
- Если я понимаю, что для работы моего предприятия придется рассчитывать зарплату на большое количество сотрудников (более 10), то мне, наверно, еще и 1С:ЗУП нужен.
- Кроме этого, я наверняка захочу установить какую-нибудь учетную программу для себя, чтобы в ней вести управленческий учет, хотя бы в моем понимании. Тем более что я, пока начинающий предприниматель, и первое время буду на 80% «серым», пока не «обелюсь». Поэтому мне будет нужно:
- 1С:Бухгалтерия, которая будет считать «как положено»
- И что-нибудь для себя, которое будет считать так, как мне это нужно. Если у меня с деньгами совсем плохо, то для себя я, наверное, буду считать в Excel.
Итак, мне понадобится какой-то набор автоматизирующих программ, потому что есть стереотип «надо сделать как у всех, а там будет видно». Это – автоматизация первого уровня.
Автоматизация второго уровня – систематизация информации
Второй уровень автоматизации уже немного постарше. Прошло какое-то время, мой бизнес начал расширяться, и я хочу получать по нему сводную отчетность, хочу считать какие-то его показатели. Теоретически их посчитать в общем-то несложно, но когда таких данных становится много, считать их вручную (или в Excel) уже неудобно.
Или, например,у меня появляется потребность в организации некой системы, которая бы позволяла моим менеджерам видеть остатки на складе. Чтобы они могли общаясь с клиентом в другой части города знать доступное для продажи количество товара. Это тоже распространенный вариант.
Автоматизация третьего уровня – увеличение производительности труда сотрудников
Следующий, еще более крутой уровень автоматизации, заключается в том, чтобы увеличить производительность труда своих сотрудников. Чтобы при тех же сотрудниках, за ту же зарплату, за то же время получать себе большую прибыль. Этот уровень уже однозначно не для новичков, потому что тот, кто начинает, никогда об этом не думает, даже теоретически.
Автоматизация четвертого уровня – приобретение новых возможностей
И, наконец, четвертый уровень автоматизации – это когда я уже большой, мощный, сильный, не хочу останавливаться на достигнутом, хочу развиваться дальше. Целью такой автоматизации является переход на новый уровень.
- По сути, первые два уровня автоматизации – это решение проблем, некое лечение, избавление от боли: «У меня есть проблема, и я ее решаю».
- А следующие два уровня – это уже, в основном, не решение проблем, а приобретение «фичи». Вроде бы и так неплохо, но я хочу еще приобрести что-то, чего у меня нет. Пока у меня есть явные проблемы, меня такие приобретения, честно говоря, не волнуют – это как в пирамиде Маслоу: пока не заполнен один уровень, следующий не возникает. Но зато, когда он возникает, он, как правило, обходится дороже, но и удовлетворение дает больше. Понятно, что реальное решение четвертого уровня гораздо сложнее, чем решение первого.
Варианты автоматизации
Вариант «по хотелкам пользователей» (направление снизу вверх)
Как выглядит типичное внедрение во многих случаях?
- Например, как я уже сказал, у меня есть некая компания, которая торгует полиэтиленовыми мешками. Это – замечательный продукт, нужен всем, всегда. Как физикам, так и лирикам. В том числе - предприятиям. Прекрасная вещь. И вот, я ими торгую.
- Допустим, у меня работает 50 человек, из них 20 менеджеров. Есть 2 склада. Фирма небольшая, но и немаленькая, средняя.
- У меня есть свои IT-шники – пара админов. И даже один или два 1С-ника.
- У меня уже стоят 1С:Бухгалтерия и 1С:ЗУП. Вопрос регламентированной отчетности я для себя, так или иначе, уже решил, это не проблема. Я содержу отдел бухгалтерии, и за какие-то деньги они мне вопрос отношений с государством закрывают. Но мне это ничего не дает.
- И я решаю поставить для себя еще некий управленческий учет, чтобы понимать, как мне торговать, как мне решать маркетинговые вопросы и т.д. Например, я хочу видеть реальные взаиморасчеты – серые, белые. Вращать этими деньгами, может быть, перегонять с одного юрлица на другое. Допустим, у меня не одно юрлицо, а три. И есть определенные правила продажи через эти юрлица, которые я хочу автоматизировать. В результате, я даю своему 1С-нику задачу подобрать мне что-нибудь под это дело. Путем каких-то совещаний, размышлений выбирается конфигурация, которая теоретически должна закрывать хотя бы какой-то процент вопросов – их большую часть. И, например, выбор останавливается на УТ или УПП.
- Дальше – как выглядит сам процесс внедрения?
Мы выбрали для себя конфигурацию, пригласили подрядчика, который нам эту коробку принес. Он нам ее поставил, развернул, обучил в ней работать мой персонал, рассказал, как вносить документы, заполнять справочники и т.д. И все. На этом его роль закончилась. Это – первый этап внедрения. Смысл в том, что на первом этапе меня «прогнули» под систему. Я работаю согласно той бизнес-логике, которая реализована в конфигурации.
- Как выглядит второй этап внедрения? В абсолютном большинстве случаев (исключения есть, но они очень редкие) мы начинаем развивать систему под свои потребности. Чаще всего мы начинаем с реализации требований отдела продаж или отдела закупок – где больше всего проблем, либо кто громче всех кричит, либо где начальник смог всех остальных «отфутболить». И даем этому отделу в полное распоряжение программиста 1С, чтобы он все их «хотелки» реализовывал. После того, как этот отдел будет автоматизирован, мы переходим к следующему отделу, и т.д. В принципе, с точки зрения нормального человека, так примерно и должно быть. И если на нашем предприятии 4-5 отделов, то за год их всех можно более-менее автоматизировать.
Но что происходит в жизни?
- Как правило, первый отдел (любой, какой бы ни был выбран) мы автоматизируем «на ура»: выполняем все «хотелки» пользователей, настраиваем все, чтобы им было удобно работать. Они счастливы, все прекрасно.
- Но когда мы начинаем автоматизировать второй отдел, нам приходится переделывать процентов 15-20 первого отдела, потому что между ними, оказывается, существуют какие-то взаимодействия, которые по факту ни первому, ни второму отделу не интересны.
- А после того, как мы переходим к третьему отделу, нам, оказывается, приходится переделать 15% второго отдела и 50% первого отдела.
- И при автоматизации пятого отдела, первый отдел нас уже просто посылает далеко и надолго, потому что мы его всем этим совершенно замучили.
В результате наша кастомизированная, сделанная под пользователей конфигурация, начинает очень напоминать деревце, на котором висит огромная куча скворечников.
В принципе, большинство проектов, с которыми я сталкивался, примерно так и протекают. Мы что-то внедряем, обучаем пользователей на этом работать, а дальше развитие уже идет с точки зрения пользователей и сводится к тому, чтобы реализовать какие-то их «хотелки». А поскольку априори нет такого сотрудника, который стал бы думать о стратегии компании в целом, мы каждый раз делаем какой-то отдельный «кусок», который никак не увязан с другими кусками (в лучшем случае, на 50% увязан). А когда этих кусков – миллион, и каждый из них на 50% увязан с соседними, то вы понимаете, что в целом эта система будет очень несовершенна.
Вариант «со стратегией» (направление сверху вниз)
Однако есть небольшой процент предприятий, которые действуют по-другому. Они действуют сверху – вырабатывают политику, стратегию и хотят, чтобы все двигалось в рамках этой стратегии. Конечно, это непросто, поэтому приходится потратить много времени на то, чтобы продумать:
- Как все должно работать,
- Как должны взаимодействовать различные данные,
- Что должно стекаться наверх,
- Какие отчеты они хотят видеть,в конце концов, наверху.
- Причем, нужный им отчет может складываться из двух других отчетов, которые в свою очередь складываются из каких-то первичных документов. Соответственно, сотрудники должны нужную для этого информацию вбивать в базу.
Но что при этом происходит? Такая автоматизация в жизни сильно растягивается во времени и, в результате, просто не успевает за изменениями в самой компании. Причем дальше второго уровня она обычно не спускается, потому что приходится по многу раз все это переделывать.
Например, если в средней компании где-то 4-5 уровней: первый уровень – это генеральный директор, коммерческий директор; второй уровень – это начальники отделов, потом идут исполнители какие-нибудь, - такое внедрение дальше второго уровня обычно не проходит, не успевает просто – даже до ввода первоначальных данных не доходит иногда.
Вариант «все в одном»
Есть еще один вариант автоматизации – это «все в одном». Когда люди покупают, скажем, большую конфигурацию, которую они хотят (например, УПП в полном развороте со всеми причиндалами, вплоть до МСФО – в ней и документооборот есть, и бюджетирование,и еще что-нибудь – сказка). Пока что у них вообще ничего не внедрено, они только выбирают конфигурацию. Но, несмотря на то, что это дорого, это – внедрение, это – деньги, они сразу хотят сделать все, что им потом когда-нибудь, вероятно, понадобится.
В результате, когда к ним приходит подрядчик и начинает обучать сотрудников, то фактически происходит так, как нарисовано на этой картинке. Потому что когда у них ничего нет, это – хаос, они находятся в больном состоянии, их организм – больной. И когда они его начинают нагружать по полной программе, желая иметь большие мышцы, бегать стометровку за 11 секунд и т.д., то на это тратится очень приличное время, и в результате все это дело заваливается. Более того, примерно половина фирм на этом умирает. Так делать не нужно.
Направления автоматизации («сверху вниз» и «снизу вверх»)
По сути, внедрение «снизу вверх» и «сверху вниз» – это наиболее распространенные две крайности, которые у нас проистекают:
- Первый вариант – это мы идем «сверху вниз», когда у нас есть начальник, который лучше всех знает, как работает его фирма, как она у него устроена, как у него в действительности работает бизнес. Во всяком случае, он искренне так полагает. И, исходя из этого, он пытается автоматизировать те бизнес-процессы, которые существуют у него в голове. Именно на основании этого прописывается ТЗ. Но я еще ни разу не встречал, чтобы это сработало, просто по той причине, что я еще ни разу не встретил того, кто действительно знает, как работает его фирма (если в ней хотя бы больше 10 человек). Потому что в действительности, когда нет автоматизации, все всегда работает на отношениях. А начальник никогда не знает этих отношений.
- И второй вариант – «снизу вверх», когда мы автоматизируем по желаниям пользователей. Это тоже ничем хорошим не заканчивается.
Какая идеология используется при внедрениях«сверху вниз» или «снизу вверх»?
- «Сверху вниз» – это человек-винтик. Цель этой системы, в том числе и с точки зрения безопасности, – это чтобы любого человека можно было заменить. Когда есть прозрачность, мы говорим, что у нас есть вот такие бизнес-процессы, мы именно их автоматизируем. И после этого нам уже ничего не страшно: есть все инструкции, все регламенты, все понятно и прекрасно работает. А мы можем заменить любого сотрудника, потому что приходящий человек тут же включается в процесс.
- И вторая система, когда «снизу вверх», – это демократия. Мы стараемся сделать счастливыми пользователей, мы делаем все для них, и в результате они нам должны дать прекрасную фирму. Раз все счастливы, значит, фирма должна работать хорошо.
«Глюки» системы
Автоматизация ради автоматизации
Вообще автоматизация является очень хорошим маркером, показывающим бардак в работе предприятия.
- Когда мы не автоматизируем, у нас работает человек с человеком, используя блокнотики, Excel, что-то еще. В процессе работы эти люди еще и общаются, понимают друг друга, договариваются – они способны мыслить не только жестко логически. В результате все строится на личных взаимоотношениях.
- Но как только мы начинаем что-то автоматизировать, возникают проблемы, потому что компьютер не понимает, что «Синяя бутылка» и «Бутылка синяя» – это на самом деле одно и то же. Люди это понимают, а компьютер – нет. У него есть такое свойство – он очень аккуратный, но абсолютно тупой. Он не может ни о чем догадаться, не может понять, что это – само собой разумеется, и т.д. В результате попытка что-то автоматизировать очень хорошо выявляет те места, где нет процессов, где нет регламентов, где непонятно, как действовать на этих незакрепленных отношениях.
И почему большинство внедрений очень часто заваливается? Потому что что бы мы ни делали, хоть снизу, хоть сверху, наша автоматизация не оправдывает ожиданий:
- Мы не приносим организации денег, не повышаем эффективность, ничего не даем.
- Если у нас нет процессов, мы ничего не ускоряем.
- Если у нас нет контрольных точек, нет описанного результата, мы ничего не упрощаем, никакой себестоимости не снижаем.
Так проявляется «глюк» системы – автоматизация ради автоматизации. К сожалению, на мой взгляд, это – 90% сегмента средних внедрений. В крупном бизнесе соотношение немного другое, но очень большой процент средних внедрений оказывается именно таким вариантом, когда люди хорошо делают немного не то.
Конфликт интересов
И здесь еще возникает некий конфликт интересов, потому что если мы что-то внедряем, то:
- Заказчик хочет, чтобы была кнопка «сделать все», чтобы все было хорошо.
- А внедренец хочет выполнить ряд каких-то действий, за которые ему потом заплатят (поскольку понятие «все хорошо» очень размытое, и вытянуть представление о нем из заказчика, который сам не знает, что он хочет, – тяжелая задача). Соответственно, внедренцы сами подталкивают заказчиков, чтобы те написали свои требования в виде действий, которые надо сделать. Мы их выполним, а вы нам заплатите деньги.
Причем тому, кому это поручается, выгодно не задумываться о результате: у него есть конкретный перечень действий. Он постарался уложиться в срок, выполнил все, что ему было предначертано, а будет это работать или не будет – проблема того, кто ставил задачу. Он же ему конкретную задачу дал, что делать. Надо сделать 20 шагов вперед. А то, что ему на пути встретилась стенка, не его проблема. Его нельзя за это ругать.
Соответственно, поскольку в процессе разработки мы не пытаемся сформулировать конечную цель, разобраться, как правильнее было бы это реализовать, результат такого внедрения никакого эффекта не приносит. Мы что-то сделали, внедрили – и этим либо пользоваться невозможно, либо мы просто в лучшем случае осчастливили своих сотрудников. Им теперь работать удобно – они теперь работают быстрее, легче, чаще пьют чай. Но делать от этого больше работы они не стали. Я что-то внедрил, затратил деньги, но остался при этом на том же самом месте.
Выбранный предмет автоматизации не соответствует реальным потребностям
Кроме этого, часто случается так, что выбранный предмет автоматизации не соответствует реальным потребностям.
Человеческий мозг устроен так, что мы живем, совершая какие-то действия. Из этого состоит наша жизнь. Поэтому человек и мыслит автоматически действиями – что нужно делать.
Эту особенность мышления наглядно показывает простой эксперимент – обычная, всем понятная задача:
«На столе лежит 5 яблок. Маша забрала 4 яблока, сколько яблок осталось?»
Задача для первого класса – из одного вычесть другое и ответить. Теперь я формулирую эту задачу по-другому:
«На столе лежит 5 яблок. Маша взяла три яблока. Сколько осталось яблок после того, как Петя доложил туда еще два?»
80% детей после того, как встретили вопрос «Сколько осталось яблок», задачу читать перестают, потому что после чтения некого набора данных, их мозг тут же начинает их обрабатывать, не разбираясь в том, что там написано дальше. Дети не дочитывают задачу.
На самом деле, так поступают не только дети. Так поступают абсолютно все. Даже человек, который хочет решить какую-то свою проблему, и запускает для этого автоматизацию. Автоматизация – это же средство для решения какой-то проблемы. И вот о том, что именно она должна решить, о цели – он думает буквально 10 секунд. После этого у него либо на основании опыта, либо еще как-нибудь, складывается некое решение, как это можно сделать. И дальше его мозг мгновенно соскакивает в размышления над этим решением, что нужно, чтобы это воплотить:
- Он решает, что надо купить программу:
- У меня есть IT-шник, надо ему это поручить.
- Надо его вызвать,
- Рассказать, какую программу я хочу,
- Попросить, чтобы он уложился в определенный бюджет,
- А потом его проконтролировать.
Его мозг пошел решать «как», а о том, «что» он хочет получить, он думает буквально 10 секунд.
- Точно так же он ставит задачу – действиями, которые нужно сделать.
- Соответственно, когда ему эти действия сдают, то перечисляют: «я это сделал, это сделал, это сделал». Все. Процесс закрыт. Если все сделано нормально, то считаем, что ситуация идеальная.
При этом получается, что о результате мы чаще всего начинаем думать только тогда, когда у нас появляется этот результат. Мы что-то получили, а теперь смотрим на это и думаем: «Я уже должен быть счастлив? Это – то, что я хотел? Или все-таки не совсем то? А что же я тогда хотел?»
Только после этого человеку первый раз приходит в голову мысль, что же он хотел и как это можно измерить.
Как получить эффект от автоматизации?
Ну и что с этим делать?
- Первым делом важно определить основного потребителя функциональности и получить от него информацию об истинной цели автоматизации.
- Причем, эта цель обязательно должна быть измерима в каких-то единицах измерения. Рубли – понятнее. Потому что когда что-то нельзя померить, его можно не дать совсем, и человек этого не заметит. Формализовать можно все. Главное – выбрать, на основе чего. Например, «сократить остатки на складе» – непонятно, чего нужно достичь. А «сделать так, чтобы остатки на складе каждый день в 5 часов вечера каждого дня не превышали миллион рублей» – понятно, чего надо достичь.
- Есть такой принцип – каждая цель, по которой можно задать вопрос «Зачем?», конечной целью не является. Целью является ответ на этот вопрос. Зачем, для чего ты хочешь это использовать? Мне нужно понять, какой у цели есть вход в нижнюю часть. И у нее есть два выхода вверху – кому и для чего. Эти вещи должны стыковаться.
Показанная на рисунке схема называется «Целевая схема», и она предназначена для того, чтобы помочь формализовать требуемый результат (цель), описать, что он из себя представляет, каким критериям он должен соответствовать, кто и когда это соответствие будет принимать, а кто – сдавать. Также в схеме описываются необходимые ресурсы, требующиеся ответственному за выполнение того или иного критерия (его встречные требования) и даются ссылки на схемы бизнес-процессов, в которых описано, как именно нужно действовать, чтобы обеспечить нужный критерий к нужному времени.
Получаемый результат обязательно должен иметь «Потребителя», т.е. – того, кто будет использовать этот, произведенный вами продукт, в какой-то своей схеме. По идее – то, что в вашей схеме стоит в коричневом овале с номером «1», обязательно должно стоять у человека из желтого кубика «2» в одной из его «Целевых схем» на месте розового овала «9».
Основная идея заключается в постулате:
На работающем предприятии только собственник, стоящий в конце цепочки потребления, может фигурировать в кубиках «2» и сам никаких схем не иметь, т.е. – может потреблять и ничего не отдавать взамен. ВСЕ остальные работники предприятия в процессе своей производственной деятельности должны производить какой-то продукт. Причем:
- этот продукт обязательно должен быть измерим в каких-то единицах (рублях, метрах, килограммах, минутах – в чем угодно). Если производимый человеком продукт нельзя померить, значит, он НЕ ПРОИЗВОДИТ НИЧЕГО и может вообще не работать совершенно без убытка для предприятия (он не нужен);
- этот продукт обязательно должен кем-то потребляться, т.е. должен существовать конкретный человек на этом предприятии, который в четко определенное время забирает этот продукт;
- у потребителя продукта он обязательно должен присутствовать в одной из его «целевых схем» в одном из розовых овалов «9» (т.е. – это должен быть ресурс, необходимый для решения какой-то конкретной задачи, производства какого-то следующего продукта).
Такая схема (целевка) строится «сверху вниз», т.е.:
- Я говорю своему начальнику отдела продаж: «Дайте мне 50 новых клиентов к концу месяца»
- Он начинает проводить меня по схеме:
- Клиент – это организация или ИП, совершивший у нас покупку не менее, чем на 1000 рублей;
- Новый клиент – это организация или ИП, совершивший у нас покупку впервые. Ранее никогда у нас ничего не покупал;
- Считаются только покупки, оплаченные не менее, чем на 70%;
- Момент проверки – 31 число текущего месяца – время 17.00.
- Дальше, по схеме, он начинает оценивать нужные ему для выполнения задачи ресурсы и выставляет мне встречные требования:
- Мне нужно трое сотрудников
- Мне нужно три отдельных городских телефона
- Мне нужна «холодная» база потенциальных клиентов не менее, чем на 1000 организаций, с контактами
- Мне нужна база данных для внесения результатов переговоров, выписки счетов, отслеживания отгрузки и оплаты (т.е. – эта база данных должна все это уметь).
Для поверхностного анализа (договориться на уровне первичного совещания) этого вполне достаточно – мы смогли договориться (причем – вполне однозначно), именно я должен дать к концу месяца и представить, во что это нам обойдется. Это позволит нам принять решение о целесообразности данного шага, а список встречных требований – это список необходимых ресурсов (т.е. мы теперь знаем, что нам нужны телефоны, нам нужны люди определенной квалификации, нам нужна база данных с определенными к ней требованиями). Мы берем этот список, каждый его пункт ставим в качестве цели и проводим для него точно такой же расклад – кто, когда, что именно и за какие ресурсы обеспечит нам этот ресурс.
Спустившись «по пирамиде» схем вниз, мы получим реальную структуру «ответственности» на нашем предприятии.
Когда я провожу подобные построения на практике, в лучшем случае 40% людей и того, что они делают на работе, имеет какой-то конкретный, выразимый в каких-то единицах, результат. Остальные просто «работу работают», т.е. делают аморфное «нечто», не совсем понятно какое и неясно кому нужное. Еще достаточно большое количество «произведенного продукта» никак реально не используется, т.е. человек целый день делает какой-то супер-отчет, сдает его руководителю, тот его читает и складывает в стопочку таких же. Отчет, конечно, интересен, но он не фигурирует ни в какой «целевке» руководителя – т.е. он НИ НА ЧТО НЕ ВЛИЯЕТ! Получается, что человек целый день трудился совершенно напрасно. Все это очень простые и понятные вещи, но в реальной практике – огромное количество именно таких «странных» несоответствий.
«Родной сестрой» целевой схемы является схема бизнес-процесса, описывающая, какие действия нужно совершить и какие решения принять, чтобы выдать требуемый результат. В «целевке» - ссылки на бизнес-процесс – это блоки «7» и «11».
Нотация не стандартная, зато отражает те вещи, которые важны для наших целей. Для каждого исполняемого шага мы должны указать:
- Кто выполняет этот шаг
- Какие ему нужны ресурсы и информация
- Полученный в результате шага материальный результат (который обязательно можно измерить)
- Потребитель этого материального результата
Схемы процессов рисуются просто по тому, что сотрудник «делает», по результатам прямого наблюдения за его работой.
Эти две схемы связаны обязательными связями:
- Для всех блоков «7» и «11» всех «целевок» должна быть схема «процесса». Т.е. – если кто-то должен выдать какой-то «продукт», значит, он должен знать, как это делать. Конечно, многие, нанимая профессионала, не очень об этом задумываются – он же профессионал, «он сам знает, как надо». Это скорее вопрос безопасности фирмы – если человек исчезнет, сможет ли его кто-то заменить, или его «знание» уникально и имеется только у него в голове. Для нас важно, что схема «процесса» существует в принципе – т.е. есть реальный процесс, обеспечивающий получение нужного продукта.
- Для всех схем «процессов» получаемые в их результате «продукты» обязательно должны стоять в какой-то «целевке» в блоке «9». Т.е. – если сотрудник что-то делает на работе, то он должен в результате этого «делания» производить какой-то продукт, который нужен кому-то для реализации его задачи.
Проведя такой анализ – построив два набора схем: «целевка» сверху и «процесс» снизу - нужно проверить два указанных требования. В моей практике множество нужных работ выполняется «уникальными специалистами», которые делают эту работу непонятно как и непонятно за какие ресурсы и время, а при этом множество работ (т.е. – то, что делают конкретные сотрудники в течение дня) не производят никакого внятного продукта, или этот продукт никому не нужен.
В идеале – только выстроив набор этих схем и состыковав их друг с другом, т.е. устранив «глюки» нашей структуры и построения работы, мы можем автоматизироваться. В этом случае вероятность успеха будет намного больше, чем до этого.
Такой анализ позволяет увидеть отрицательные результаты будущей автоматизации до того, как мы эти результаты получим, что дает нам возможность сэкономить огромное количество времени и ресурсов.
************
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года.
