День первый. Вторник

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

После приветствия и поздравлений, босс сказал только одну фразу:

"Что-то мне последнее время не нравится, как идут дела, попробуй-ка разобраться в этом. Разберись и покажи, чем может помочь автоматизация. Времени у тебя целых две недели".

И что теперь делать? За что хвататься? И с кем разговаривать? Я что, антикризисный управляющий? Надо немного успокоиться, кофе пойти выпить. В конце концов, никто меня сюда идти не заставлял. Сам решился, понимал, что дело важное, ответственность...

Паровоз должен идти

Инженерное образование должно выручить и на этот раз. Начнем с самого начала. Откуда берутся у организации деньги? В производственном цикле они только тратятся. В управленческом тоже денег не зарабатывают. В отделе маркетинга в основном изучают и рекомендуют. В бухгалтерии считают. Продажи: остаются продажи.

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

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

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

Как же убедиться, что основная часть бизнеса функционирует нормально? И что я могу для нее сделать хорошего?

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

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

Надо как-то описать и проверить текущее состояние нашего бизнеса, сделать экспресс - оценку. И чем нам тут может помочь автоматизация? Знал бы прикуп: давно бы ездил на "Мерседесе".

Что продаем?

Это выглядит не совсем логично, но начнем с самого конца. Поэтому первое, что сделаем - пойдем в отдел продаж и постараемся выяснить, что и в каком количестве мы сегодня продаем. Оказывается, есть несколько практически независимых направлений. Услуги, реализация оборудования, монтаж и настройка оборудования.

Теперь надо выяснить конкретную номенклатуру услуг...

И сразу же разочарование. Устойчивый прайс-лист есть только на услуги, и то не на все.

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

Придется разговаривать с менеджерами по направлениям. Менеджеры почему-то с опаской относятся к тому, что их спрашивают об объемах и просят показать, что и за сколько они продают. Интересно, почему? Нормальная реакция - показать здоровую стопку актов. Ну и как я с ними буду сейчас разбираться? У меня времени 2 недели, а тут работы на месяц. Ладно. Попробуем хоть как-то классифицировать продукты по направлениям и способам продаж.

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

День второй. Среда

Второй день работы принес еще больше новой информации и разочарований. Оказывается, конкретные цифры по зарплате, да и другим расходам, знает только один директор, который пока далек от мысли поделиться ими. Да и с продажами, чем дальше я продвигался, тем больше возникало "белых пятен": оказывается, сами процессы продажи и отгрузки очень зависят от направлений, продукции и способов оплаты. Надо будет с этим разобраться, о двигателе нашего паровоза я должен знать все. Штатное расписание с фамилиями я все же получил, только что оно мне дает, кроме кандидатов в знакомых по курилке?

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

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

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

Из философии вспоминаются отрывки, что структура - это точка зрения на систему, ее строение, ее элементы. Значит, структур может быть много. Я себя тоже в штатном расписании нашел, значит, я элемент штатной структуры. Это надо перекурить:

Экономист мне подсказала, что правильнее говорить "оргструктура", а не штатная. Ладно, спасибо девушке, я еще с ней познакомлюсь поближе. Надо будет изобразить эту оргструктуру, желательно бы наглядно (боссу ведь показывать). И что-то мне подсказывает, что не сразу босс согласится с моим рисунком, да и будущем будем его вместе дорабатывать, так что и версии хранить надо, и в сетевом режиме работать над оргструктурой предстоит. Пока сделал, в чем знал, в MS Visio, и торжественно представил боссу. Я чувствовал себя как минимум первооткрывателем. Но оказалось, что нечто подобное босс уже сделал, то ли сам, то ли с консультантами (надо бы узнать, что это за типы, в моей оргструктуре их нет), и тоже показал папку красивых рисунков и текста. "Красиво, - говорит он, - но непонятно, как это применить и что для этого сделать".

Да, думал удивить, а оказывается, я повторил уже чей-то труд. Но нутром чувствую, что стою-то я на правильном пути, и нужно только продвинуться дальше.

Утро вечера мудренее.

День третий. Четверг

С чего я вчера сделал открытие оргструктуры? Почему колеса в моей машине поворачивают, куда надо, а двигатель работает в правильном режиме? Все они получают сигналы друг от друга, но в конечном счете - от водителя. Вдруг вспомнилось из единственного занятия по теории, которое я посетил на курсах вождения, что процесс торможения состоит из времени реакции водителя и времени самого торможения колес. Даже простое прикладывание колодок к дискам - уже процесс. А моя компания уж посложней автомобиля будет, это скорей какой-то организм, живущий по своим правилам, переваривающий кучу денег, в котором люди приводят в работу этот самый организм и получают за это свою часть денег. Это уже скорее какая-то биология и анатомия, которые еще в школе вызывали стойкое отвращение. Помню только "метаболизм" - это процесс обмена веществ. Вот именно, опять процесс! Двигатель в машине - внутреннего сгорания (сгорание, "делание" т.е. действие, растянутое во времени), менеджеры в продажах тоже мне говорили, что продажа - это "Процесс", причем именно с большой буквы.

В общем день прошел под лозунгом "все дело - в процессах". Хотя уже дома и "все дело - в перце" тоже пришлось в тему, даже жена после монолога о процессах не возражала и смотрела уважительно.

День четвертый. Пятница

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

Короче, нужно как-то нарисовать современные процессы работы в компании, и представить их боссу вместе с указанием проблемных (дефективных, аварийных, опасных) мест.

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

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

День пятый. Суббота

Друг грузил по полной, надо со всем этим разобраться, так что я решил изложить в том виде, как законспектировал.

Нарисуем - будем жить

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

Системы проектирования изначально разрабатывались для нужд конструкторов и инженеров - технологов, это всякие CAD/CAM - системы. Это действительно сложные программы, и их возможности в визуализации нам едва ли могут помочь. Поэтому этот класс систем сразу оставим специалистам. Вот изверг. Мог бы сразу про эти программы и не говорить.

Следующим классом являются системы моделирования. Найдем ли мы что-то интересное здесь? Очень большую часть этого класса составляют системы, которые принято называть CASE (Computer Aided Software Engineering). Уже из названия видно, что они разрабатывались не для бизнеса, а именно для того, чтобы повысить качество и скорость разработки программ. Поэтому туда нам, казалось бы, тоже незачем заглядывать. Однако есть несколько ярких представителей, которые тоже относятся к CASE - системам. Например, BPWin, Rational Rose. Эти два продукта интересны потому, что они реализуют две совсем разные нотации, IDEF и UML соответственно. Нотация - это что-то типа способа описания и визуализации.

BPWin интересен инженерным подходом к описанию бизнес - процессов предприятия на основе стандарта IDEF, он у американцев распространен.

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

Но я себе представил около полсотни страниц описания, и мне стало понятно, что без наглядности для босса презентация провалится. Разобраться сложно в таком скоплении стрелок, а не то что что-то менять и улучшать.

Если честно, то IDEF творческому процессу моделирования способствует не очень. Все это гораздо больше похоже на не самое любимое мной черчение. Связано это с тем, что IDEF разрабатывался еще в те времена, когда об использовании компьютеров для моделирования, только начали задумываться, отсюда и основные рекомендации по построению схем. Например, использовать по 3-6 узлов на диаграмме, способы нумерации блоков и их декомпозиции (детализации). Все это было вполне естественно для тех, кто имел дело с бумажными чертежами, но сейчас вызывает все большее недоумение. Интересная идея с различными значениями сторон блоков каждого из узлов диаграммы тоже требует привычки. Левая сторона блока предназначена для входов, верхняя - для управления, правая - для выходов, нижняя - для механизмов. Такое обозначение отражает определенные системные принципы: входы преобразуются в выходы, управление ограничивает или предписывает условия выполнения преобразований, механизмы показывают, кто, что и как выполняет функция. Узлы могут быть связаны не только привычным нам образом выход одного со входом другого, но и по управлению, что иногда выливается в не очень простые для интерпретации схемы. Например, совершенно нетривиальная задача - описать действие в зависимости от условия, хотя к этому мы все уже давно привыкли. IDEF0 для этого просто не предназначен. Обилие текстовых меток, которые надо наносить на диаграмму, чтобы она стала понятной, наводят на мысль, что использовать результат, кроме как схему просто невозможно.

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

Еще есть набор продуктов "БИГ: Структуризатор". С его помощью можно описать элементы различных структур и проекции на них, а также попробовать порисовать IDEF - диаграммы. По цене он до 2 - 3 тысяч долларов, и может помочь в описании структур компании, особенно на начальных этапах. Проблема возникает с ним дальше - как перевести все разработанные структуры и процессы на уровень исполнения, как связать с системами для учета / планирования. Да и недостатки IDEF уже упоминались.

Еще есть продукт "1С-Инталев: Бизнес-Архитектор", который по возможностям примерно то же самое, что и "БИГ: Структуризатор", только на платформе "1С: Предприятие 7.7", но без рисования процессов в IDEF. Зато имеет тесную интеграцию с другими конфигурациями и продуктами для 1С (удобно, например, список сотрудников автоматически выгрузить из базы 1С или разработанную структуру справочника загрузить обратно в 1С), и технически более открытый. И стоит около 600 долларов.

Rational Rose для нас гораздо менее актуальна именно потому, что она ориентируется на стандарт UML, который хоть и предназначен для описания процессов и взаимодействий, но явно демонстрирует свое реальное и оригинальное назначение - служить языком для описания информационных систем. Эта нотация скорее применима для описания номенклатуры бизнес - функций и простых алгоритмов их исполнения, и ее совсем не просто совместить, например, с реальной организационной структурой предприятия. И наглядность тоже падает.

Еще одной программной разработкой, о которой обязательно хочется вспомнить, является ARIS (Architecture of Integrated Information Systems) фирмы IDS Sheer. Эта система демонстрирует стремление к всеобъемлющему подходу при описании бизнеса. Ее уже трудно отнести к CASE системам, поскольку она ориентирована именно на описание бизнес - процессов организации, а не на создание программного обеспечения. Методология ARIS рассматривает предприятие как совокупность четырех взглядов:
взгляд на организационную структуру,
взгляд на структуру функций,
взгляд на структуру данных,
взгляд на структуру процессов.

При этом каждый из этих взглядов разделяется еще на три подуровня: описание требований, описание спецификации, описание внедрения.

ARIS считается одним из лидеров в направлении моделирования бизнеса, и не даром в 2002 году было продано более тридцати тысяч лицензий ARIS.

Однако продукт этот - западный. А значит - трудности с локализацией и поддержкой (у нас вот босс филиал в Иркутске собирается открывать), да и цена от 10000$ кусается.

Чтобы закончить с программами для "уплотнения" информации, надо еще заглянуть на какую-нибудь из программ для подготовки графических материалов, или презентаций. Пожалуй рассмотрим на одну из самых развитых и распространенных программ для работы с деловой графикой - MS Visio. Сама по себе программа очень разнообразна и обладает хорошим потенциалом. Но единственная ее проблема, которая губит многие системы - стремление к универсальности. Лучшее - враг хорошего. Именно в силу универсальности она не может считаться ни идеальным средством моделирования баз данных, ни выдающимся средством проектирования, ни удачным средством для простого рисования картинок. Место этой программы вполне понятно - это развитое средство подготовки разного рода диаграмм и графических материалов и одновременно недорогое средство моделирования, от которого не надо ждать серьезной помощи в решении сложных задач, но которое вполне справляется с тем, что уже стало общепринятыми нормами, например - построение UML-диаграммы. Я и сам в ней оргструктуру по-быстрому накидал, но теперь просто вывести список всех должностей или сотрудников уже требует программирования макроса, версии оргструктур хранить не в чем, а сами должности не могут быть элементами общего списка, чтобы использовать их в процессах. В общем, "рисовалка". Итак, Visio нам похоже не подходит. Я почти уверен, что и все программы из этого класса будут столь же полезны. Ну действительно не в PowerPoint же оргструктуру рисовать? Хотя прецеденты есть.

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

Короче говоря, нельзя заставить компанию, вернее, ее сотрудников, работать по спроектированным процессам. Можно напечатать тома схем, раздать всем инструкции, но нельзя быть уверенным в том, что именно так и только так в реальной жизни эти процессы будут исполняться. Особенно, если нет программ, которые контролируют правильность действия персонала. Так что толк от таких схем половинчатый: ясность вносят, но уверенности в ее соблюдении не дают. А я же начальник отдела автоматизированных СУ, так что, чует мой разум, что можно и нужно автоматизировать процессы. Поначалу хотя бы часть, наиболее рутинные и формализованные.

Так что мне нужны не только статичные картинки на стол босса, но и - потом - их перенос в динамику каждодневного исполнения. Я, конечно, размечтался получить "все и сразу", но нарисовать красивые и убедительные перспективы боссу - моя задача №1 на испытательном сроке.

И все-таки она вертится!

Дальше мы уже разговаривали именно о динамике. Собственно весь разговор шел о технологии, которая известна уже достаточно давно и называется "управление потоком работ" - WORKFLOW. Самым ярким представителем здесь являются продукты фирмы Staffware.

Stafware пошла по интересному пути, который существенно отличается от многих и демонстрирует определенную жизненную позицию фирмы. Фирма явно обозначила область своей компетенции и уверено в этой области лидирует. Программный продукт для автоматизации потоков работ этой фирмы представляет собой практически автономный сервер, в рамках которого можно определять и исполнять большое количество процессов. Интересно, что потоки являются именно потоками, поскольку одной из основных абстракций этой системы являются очереди, к которым могут быть подключены пользователи, или специальные программы-роботы. История программы восходит к Unix - системам, и это во многом определяет ее архитектуру и неприхотливый интерфейс, но в целом это интересная и серьезная разработка. Интересно, что здесь становится совершенно очевидным, что поведенческая часть системы может быть отделена от той части, с которой мы привыкли иметь дело - "статикой". Интересно и другое. Система эта появилась уже более 10 лет назад, но это до сих пор так и не привело к существенному смещению фокуса в процессах разработки приложений.

Уже существует и совместная разработка Staffware и IDS Sheer (см. ARIS) -Staffware Process Monitor (SPM). С помощью SPM удается оценить организацию работ, сравнить фактические показатели производительности с запланированными, вести историю измерения процессов по дням, месяцам и т. п., предусмотреть вывод предупреждающих сигналов в случае, если контрольные показатели сильно ниже (выше) допустимых и др.

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

Есть еще продукты Workflow, например, Lotus Workflow или "Оптима", мы рассмотрели Staffware как лидера этого сегмента.

Проблем у систем класса Workflow несколько:
не везде реализовано графическое проектирование процессов (иногда даже с помощью кода, это вообще нонсенс!)
проектирование только части процессов, которые автоматизируются, и на очень детальном, программистском уровне (параметры, условия, переходы)
не всегда есть связь с системами описания бизнес - процессов. Вернее, есть только у связки "ARIS + Staffware", а ее стоимость начинается от 25000 зеленых. А ведь было бы естественным сначала спроектировать процессы "на верхнем уровне", а потом перенести их в "динамику" для исполнения
слабая связь с другими системами, в первую очередь, с учетными программами, и далее - с системами класса MRP-ERP. Ведь наиболее часто в рутинных бизнес-процессах используются документы, которые являются объектами этих систем: заявки, счета, накладные, приказы и т. п.

Пожалуй, в этих интересных подходах не хватает чего-то простого и естественного, такого, чем обладает, например, "1C:Бухгалтерия" - простого способа переходить от описания объекта к работоспособному приложению. Действительно, весь цикл уже присутствует, создать описание бизнеса - можно. Определить поведение - можно. Осталось только уметь преобразовывать описание того, что мы привыкли называть документом (или схемой процесса) в рабочее приложение, желательно без использования программистов - и вот мы у цели. Фактически, мы действительно находимся на пороге синтеза систем управления предприятием, но перейти этот порог в новый класс систем нам все еще не удается.

Вот мы и разобрались "as is" среди ПО для бизнес - моделирования. Не густо, но и не пусто.

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

День седьмой. Понедельник

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

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

1. Идеалистический

2. Реалистический.

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

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

Хотелось пообщаться со специалистами, которые бы имели сами практический опыт проектирования и внедрения бизнес-процессов, имели бы проверенные (сначала - на себе) методику и инструменты этой деятельности, и чтобы результаты этой проверки были бы как-то авторитетно признаны, а не "на коленке" сляпаны.

День восьмой. Вторник

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

Сначала составили классификатор оргструктуры, т.е. просто иерархический список отделов, служб и должностей. Потом составили простой список сотрудников - просто Ф.И.О. А потом установили связи между сотрудниками и должностями, сделав двухмерную проекцию из этих двух классификаторов с простой связью - "Есть / нет". Это они так выразились, а по - простому говоря - сделали штатное расписание. Я сразу прикинул, что если у этой проекции добавить еще один тип связи - "Оклад", то можно получить штатное расписание с окладами. А если добавить еще одно измерение, период, например, с помесячными значениями, то можно так и планировать изменение оргструктуры и перемещения сотрудников, а также их оклад.

Мощь этой темы - классификаторов и проекций мне понравилась, ведь получается универсальное средство описания предметных областей, так что я обратил внимание на инструмент, которым они пользовались - "1С-Инталев: Бизнес-Архитектор".

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

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

Ребята сказали, что такую работу они сделали за полтора месяца, вместе со всеми согласованиями, для примерно 50 процессов. У нас может и 3 месяца такая работа занять, но ее комкать - все равно что экономить на фундаменте высотного здания.

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

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

Еще предложили после каждой функции указывать событие - означающее завершение / результат функции и начало. Учтем, это из ARIS идея, я помню, полезная фишка.

Сначала бизнес-процессы рисовали в ARIS, но сейчас будут переносить их все в собственный "Инталев: Бизнес-Архитектор, версия 2". Дело в том, что по каждому процессу очень нужно создавать кроме схемы текстовый регламент, описывающий все нюансы и условия, с навигацией в регламенте и между ними, с возможностью оперативного внесения изменений, которые для развивающегося бизнеса постоянны и неизбежны. И еще одна причина отказа от ARIS - это уже упоминавшаяся ранее разорванность между моделированием процессов и их исполнением - говорят, что "Инталев: Бизнес-Архитектор, версия 2" решит эту проблему. Посмотрим, т.к. что-то неумолимо подсказывает мне, что испытательный срок я пройду.

Бизнес-процессы внедряли их поэтапно, не дожидаясь составления полного описания. Причем рутинные бизнес-процессы сразу же автоматизировали с помощью "Инталев: Бизнес-процессы", это система из класса Workflow. Она гораздо доступней Staffware по цене, а также изюминкой является ее интеграция в систему "1С: Предприятие 7.7". А у нас тоже бухгалтерия работает в "1С:Бухгалтерия", да и менеджеры работают в "1С:Торговля и Склад", даже директор в нее, бывает, заглядывает. К 1С уже привыкли, ее обслуживаем, так что удобно будет унифицировать платформы.

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

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

Мне показали работающие настроенные бизнес-процессы в "Инталев: Бизнес-процессы":

1. Выплата денежных средств

2. Заказ ресурсов (консультантов и техники)

3. Заказ билетов

4. Заявка на работу в выходные

5. Заявка на комплектацию программных продуктов и отгрузку

6. и т.д.

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

День девятый. Среда

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

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

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

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

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

День десятый. Четверг

Практически весь день старался свести воедино все разговоры, схемы, свои и чужие мысли. Неплохо поработали и с коммерческим. Порисовали немного. Похоже я уже знаю, что покажу боссу, и смогу рассказать ему, как будет строиться работа. Начнем мы естественно не с автоматизации, а с формализации оргструктуры и описания бизнес-процессов. Революций делать не будем, а будем постепенно внедрять новые бизнес-процессы и развивать наши системы бухгалтерского и оперативного учета, планирования и бюджетирования: Через бизнес-процессы я объясню ему причины проблем и покажу их решения, хотя уверен, что и сам босс их понимает или увидит на схемах. А еще я расскажу, что всеми нужными процессами будет рулить программа, и никакого человеческого фактора. Это должно подействовать. Жаль, конечно что не получится показать все сразу и в числах. А какая была славная мысль сразу найти откуда берутся деньги и все такое... Ну да не все сразу.

Эпилог

Все прошло прекрасно: Босс поздравил меня с хорошо сделанной работой. И только в самом конце как-то странно посмотрел и задал свой вопрос: "Ты знаешь человека, который сможет это внедрить?". Ничего не оставалось делать, как сказать: "Знаю!".

Комментарии: (0)   Рейтинг: