Dimdim SoftWare
Мастерская Dr.dimdim
ГлавнаяПоискНаписать письмо
ГлавнаяМоделированиеПроектированиеТЗРазработкаИнтерфейсСтатьиСсылкиАвтор
Главная > Внедрение

Внедрение без обмана.


Статья написана директором по информационным проектам Консультационно-Внедренческой фирмы "ИНТАЛЕВ" Алексеем Федосеевым и предназначена для руководителей предприятий, которые начали задумываться об автоматизации. В ней в дискуссионной форме обсуждаются наиболее животрепещущие вопросы внедрения делового программного обеспечения.

Давно и безвозвратно канули в Лету те благословенные времена, когда заботы IT-менеджера сводились почти исключительно к установке и сопровождению серверных и клиентских операционных систем. Все чаще и чаще на информационную службу возлагается ответственность за автоматизацию бизнес-процессов. В круг ваших знакомых и любимых обязанностей активно вторгаются новые, — связанные со спецификой различных областей учета и управления. Впрочем, термин «вторжение» не популярен. Повсеместно используется его более мягкий синоним, означающий, если вдуматься, то же самое — ВНЕДРЕНИЕ.

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

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

2. Одно внедрение приравнивается к трем пожарам.
Да, головной боли у вас определенно прибавится. Но коль скоро необходимость внедрения объективна (см. п.1), сопротивляться ему — дело бесперспективное. Правильнее с самого начала занять в процессе свое достойное и важное место.

3. Внедрение не сводится к покупке коробки.
Любой софт требует сопровождения. Деловой особенно. Кто и как будет осуществлять все изменения законодательства и учета на вашем предприятии? Если же изначально ясно, что внедрение предполагает проект с составлением ТЗ, кодированием и проч., то имейте в виду, что:

4. Самостоятельное внедрение так же эффективно, как и самолечение. «Минздрав не рекомендует».
Простых областей учета и управления — нет. На изучение и кодирование потребуются месяцы и годы работы. Ответственность — огромна. Результаты — призрачны. Вам это надо?

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

6. Всякой коробке свое время.
Покупать коробку лучше всего только перед началом опытной эксплуатации, а ни в коем случае не в начале проекта. Проследите, чтобы в ТЗ были четко определены все технические и экономические условия. Если они не выполнены, — не принимайте работу и требуйте ее исправления до этапа опытной эксплуатации.

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

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

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

10. Ваша позиция и авторитет будут зависеть от результатов внедрения.
Успешное внедрение будет вашей заслугой, и это справедливо. Неуспешное... (см .п.8.). Помните, что ваша роль во внедрении — координатор. За постановку задачи и экономическую сторону дела отвечает руководство и конкретные предметные специалисты вашего предприятия, за выполнение работ, качество и сроки — отвечает фирма, осуществляющая внедрение. При правильном построении документальной среды внедрения за любой срыв должны отвечать либо те, либо другие. А ваша четкая и твердая позиция приведет к тому, что ваш авторитет увеличится даже и в этом случае.

Внедрение, или Как пойти туда, знаем куда

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

Постулат второй. Сложный маршрут, а простых внедрений не бывает, всегда состоит из этапов.
А теперь, внимание — парадоксально, но в общем случае любое внедрение имеет фиксированное количество обязательных этапов. Можете называть этот парадокс правилом «ИНТАЛЕВ». Что это за этапы?

Этап 1. Стратегическое планирование.

Топ-менеджеры компании должны сформулировать свои бизнес-цели и стратегию на ближайшие 1-2 года. Подчеркиваю, это задачи именно высшего руководства. Пока оно, нет, лучше они, не дадут своих ответов, всякая автоматизация бесполезна, ибо неясна ее цель. Так, нельзя идти просто в горы (именно поэтому умные туда не ходят). Между походом в Гималаи или в Карпаты есть, согласитесь, некоторая разница.
Хотя «ответов» — это громко сказано. Как правило, цели впервые ясно и четко формулируются как раз в результате этого этапа.

Этап 2. Формализация бизнес-процессов.

После понимания задач в бизнесе можно переходить к следующему этапу — постановке задач на автоматизацию. Кратко, для топ-менеджеров должно быть понятно описано, — какие задачи будут автоматизированы и как. В ходе этапа составляется 5-15 схем движения информации (по одной на функциональную область — планирование продаж, закупка, хранение и т.д). На этом этапе в работе принимают участие топ-менеджеры, ведущие специалисты, начальники подразделений подготовки и IT-менеджер. В результате этого этапа цели руководства будут сформулированы на языке конкретных функций и задач всех подразделений фирмы. Таким образом, это, фактически, этап постановки задачи.

Важность этих двух этапов можно продемонстрировать следующим примером. Один из наших Заказчиков — крупное производственное предприятие, выбрало нас в качестве субподрядчика для разработки ТЗ и его кодирования. Все наши доводы насчет необходимости планирования и постановки задачи были отметены. Руководство было непреклонно и не хотело (или не хотели?) «тратить время и деньги», — сразу же ТЗ! Мы предупредили о высокой вероятности неуспеха такого подхода. Увы, руководство сразу же спустило весь процесс написания ТЗ на начальников отделов, которые, естественно, не представляли системно всех задач. Мы их также не могли знать, поскольку это был не наш бизнес, не наше предприятие. После скоропостижного утверждения ТЗ и его кодировки выяснилось, что добрая половина автоматизированных бизнес-процессов была просто не нужна, поскольку руководство решило изменить их схемы выполнения, в другой половине были обнаружены грубые промахи (например, вследствие неверного понимания учетной политики). В результате тысячи долларов и несколько месяцев работ были потрачены для Заказчика впустую, о вероятности чего мы и предупреждали.

Этап 3. Оптимизация бизнес-процессов.

Постановка задачи на автоматизацию. После завершения предыдущего этапа мы получаем формализованное представление тех целей, которые ставит руководство, и тех бизнес-процессов, которые должны привести к достижению этих целей. Обычно это ПЕРВОЕ системное и реальное представление. А значит, почти всегда неоптимальное.
Обычно в результате оптимизации происходит реорганизация либо структуры предприятия, либо бизнес-процессов — реструктуризация и реинжиниринг соответственно. Зачем это нужно? У одного из наших Заказчиков в результате оптимизации мы провели реорганизацию складского учета, приведшую к трехкратному уменьшению складских потерь (продукты были скоропортящиеся). В результате принятых решений (и только после него) можно корректно определить перечень бизнес-процессов, подлежащих автоматизации, и план работ по автоматизации.

Этап 4. Техническое задание.

Опираясь на утвержденную постановку, можно разрабатывать ТЗ. Иными словами, постановка задачи отвечает на вопрос: «Что надо автоматизировать?», а ТЗ — «Как конкретно надо автоматизировать?». ТЗ составляется с IT-менеджерами и начальниками отделов — «собственниками бизнес-процессов». В нем детально описываются все объекты информационной системы, их поведение и т.д. И чем детальнее будет ТЗ, тем лучше. Не успокаивайтесь, если вам скажут, что «не надо это описывать, это и так понятно».

Документировать надо. В противном случае все кончается примерно так. В момент сдачи-приемки ваши предметные специалисты с возмущением говорят, что не примут работы, апеллируя это тем, что: «нам ГОВОРИЛИ, что это будет сделано так, а сделано по-другому». Возникает коллизия, для разрешения которой одно средство — ТЗ. Все туда дружно смотрят. Скорее всего, как там написано, так и сделано. Формально прав внедренец (какое ужасное слово!) И теперь выбор в его руках — делать уступку и переделывать (платно либо бесплатно), или нет. НЕ ОТДАВАЙТЕ СВОЙ ВЫБОР В ЧУЖИЕ РУКИ.

Этап 5. Кодирование.

После утверждения ТЗ можно приступать к кодированию. Это самый неинтересный этап. Внутреннее дело внедряющей организации.

Этап 6. Разработка должностных инструкций.

На самом деле этап 5 и этап 6 не обязательно должны быть последовательны. То есть, даже наоборот — лучше, чтобы они были параллельны. Их задача — подготовка этапа опытной эксплуатации — необходимо обучить пользователей работе с системой (а иногда и с ПК) и выдать им должностные инструкции. Без этого созданная система пропадет, как бы хороша она не была. Встречаются Заказчики, пытающиеся сэкономить на этом этапе. Все та же псевдоэкономия времени и денег. Печально вздыхаем, — как правило, на этапе опытной эксплуатации они сами попросят сделать должностные инструкции. В итоге теряется время.

Этап 7. Обучение пользователей.

Совершенно необходимо. В результате внедрения практически всегда происходит реинжиниринг и реструктуризация. Это значит, что ваши сотрудники будут вынуждены работать по-новому. И проблема состоит не только в том, что их нужно известить о грядущих изменениях и научить работать в новых условиях. Основное, пожалуй, в том, чтобы преодолеть психологическое сопротивление переменам, позитивно настроить коллектив. Раньше это называлось — «учесть человеческий фактор».

Этап 8. Опытная эксплуатация.

Закодировано начинается опытная эксплуатация. Очень важный этап. Этап, на котором можно объективно оценить все сделанное ранее. Система начинает работать не на бумаге. Требуйте ее четкой и правильной работы.

Внедрение, или Как принести то, знаем что

С тем, как строить маршрут разобрались. Но (помните?) — важен маршрут и экипировка. Утверждаю, — роль экипировки в многотрудном деле внедрения играет документированность результатов (кстати, этимология понятий «экипировка» и «оформление» представляется близкой, — правда, я не лингвист).
Итак, есть сложная, но результативная последовательность этапов. Каждый этап должен быть задокументирован и утвержден Заказчиком. Первый документ этапа — план его выполнения. Второй — план-факт исполнения работ. Третий — собственно результат этапа — «Отчет о постановке задачи», «Схемы автоматизируемых бизнес-процессов», «Техническое задание», «Должностные инструкции».

У фирмы-внедренца (ой, опять новояз) должны быть стандарты на эти документы, причем в таком виде, чтобы потенциальные клиенты всегда могли с ними ознакомиться. Нет единого стандарта? Внедренец готов работать по любой предложенной Заказчиком форме? — плохой внедренец. Нельзя плясать под дудку Заказчика, ведь он не профессионал. Только представьте — (не дай Бог) приходите вы к врачу, — а он вас спрашивает: «как будем лечиться?». То есть, нужен еще один документ. В начале каждого этапа Заказчик должен утвердить формат документа результата по этому этапу. Хорошо, если этот формат будет совпадать/коррелировать с общепринятыми — ГОСТы, IDEFы. Цель — предсказуемость результата.

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

Время внедрения

Итак, сроки. На сакраментальный вопрос: «Я хочу автоматизировать то-то и то-то, как быстро вы мне это сделаете?» Как правило, следует сакраментальный ответ: «Давайте, уточним, что именно вам нужно. Ответ будет зависеть от этого.» Вопрос — правильный. Ответ — нет. На самом деле, — сроки внедрения в первую очередь определяются не сложностью задачи. Сроки внедрения определяются СКОРОСТЬЮ ПРИНЯТИЯ РЕШЕНИЯ ЗАКАЗЧИКОМ (при профессионализме внедренца, разумеется).

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

Теперь про автоматизацию. Постановка задачи на автоматизацию зависит (сильно) от той среды, в которой будет происходить автоматизация. Информационные потоки нельзя проектировать в отрыве от среды их воплощения. Еще конкретнее — постановка задачи процентов на ... (много!) определяется тем средством, которое будет выбрано для решения. Ставить задачу будет руководство вашего предприятия и предметные специалисты. Как хорошо они представляют средства, с помощью которых задача будет решаться? Вопрос риторический. На самом деле, постановка задачи на автоматизацию системы управления (предприятием, функциональной областью деятельности или конкретным бизнес-процессом)- это процесс, в котором принимают РАВНОПРАВНОЕ участие две стороны — внедряющая фирма, которая (как предполагается) хорошо владеет средствами автоматизации, и специалисты вашей фирмы. В процессе внедрения последним придется узнать гораздо больше нового, чем специалистам внедряющей фирмы (говорим о настоящем!). Вывод тривиален — время, которое придется затратить специалистам и руководству вашего предприятия на выбор оптимальной схемы информационных потоков и бизнес-процессов (ведь решение принимать им, а не внедренцу), существенно больше того времени, в течение которого специалистам внедряющей фирмы (повторюсь, если они настоящие), придется разбираться в нюансах бизнес-процессов вашего предприятия для подготовки вариантов этих схем.

Пример. Время, в течение которого мы ставили и автоматизировали комплексную систему управления предприятием (автоматизация систем планирования, учета, контроля и анализа) одному из наших Заказчиков, составило три месяца. Время, в течение которого мы ставили и автоматизировали подсистему расчета зарплаты другому нашему Заказчику (оба сравнимы по количеству персонала) составило полгода. Подчеркну, время автоматизации аналогичной подсистемы в первом случае заняло бы 2 недели. И в том, и в другом случае работали одни и те же наши специалисты. В чем разница? В скорости принятия решения Заказчиком. В первом случае речь шла о коммерческом предприятии с жестким механизмом управления и слаженной, заинтересованной в результате командой, во втором — о постсоциалистическом предприятии с богатой наследственностью.

Иными словами, хорошая внедряющая фирма должна, как минимум, «не тормозить» процесс автоматизации больше, чем сам Заказчик. Аналогичная формулировка в медицине может звучать примерно так — хороший врач, как минимум, не должен «тормозить» процесс выздоровления больного.
Если же вернуться к вопросу, с которого начали, — «сколько времени займет внедрение?», то после 2-4 встреч с руководством фирмы-Заказчика, каждая продолжительностью около часа, время внедрения можно будет оценить с погрешностью около 40%. На этом этапе уже станет ясна и примерная сложность задачи, и то, как и сколько времени Заказчик реагирует на предложения и вопросы, сколько у него ответственных, существует ли ясный механизм принятия решения и т.д. Продолжая медицинские аналогии, серия этих встреч — не что иное как бесплатное предгоспитализационное обследование (общий диагноз, выявление всяких аллергий, противопоказаний и проч.).

Деньги внедрения

Сколько стоит внедрение? Автоматизация — это бизнес. Обычный, нормальный бизнес. Значит, определение стоимости процесса описывается общими экономическими законами — без чудес. Трудовая теория формирования стоимости (да-да, старые добрые Адам Смит с Карлом Марксом) — это классика. По ней и по жизни — прибавочная стоимость создается наемным трудом. В нашем случае трудом специалистов внедряющей фирмы. Значит, труд среднего специалиста средней внедряющей фирмы объективно определяется временем его работы. Поэтому у каждой внедряющей фирмы единица трудозатрат определяется квалификацией персонала — эта единица является базой для расчета. А как на практике устанавливается стоимость внедрения? Нам известно три способа договорного определения стоимости внедрения.

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

Способ 2. Проектный.
Способ, любимый руководством автоматизируемых предприятий за кажущуюся простоту и ясность. Нет, способ, действительно, ясный, но вот последствий этой ясности Заказчик себе, как правило, не представляет. И это может привести к серьезным проблемам.
Коротко суть проектного способа определения стоимости внедрения. Стороны четко оговаривают, что, в какие сроки и за какие деньги будет сделано. Серьезная внедряющая фирма формализует это в договорных документах следующим способом: Постановка задачи определяет, что именно должно быть сделано; ТЗ определяет, как должно быть сделано то и только то, что определено в Постановке; Кодирование — кодируется то и только то, что определено в ТЗ. Такая система позволяет внедряющей фирме точно определить себестоимость и стоимость проекта, а также планировать ресурсы. НО! Что произойдет, если после подписания договора и Постановки задачи Заказчик вдруг обнаружит, что по какой-либо причине стоящие задачи изменились таким образом, что часть заявленных в Постановке задач в том виде, в каком они акцептованы внедренцем, ему УЖЕ НЕ НУЖНА?! Внедряющая фирма на основании подписанных простых и ясных документов имеет полное право (по крайней мере, доказать это в любой инстанции не составит труда) сделать ненужную работу и добиться оплаты ее договорной цены. Кроме того, коль скоро сроки работ определены, то внедряющей фирме не выгодно их растягивать — норма прибыли уменьшается, и она обязательно будет использовать подписанные документы с оговоренными сроками для того, чтобы не дать Заказчику затянуть сроки (увеличить скорость принятия решения Заказчиком).
Иными словами, при проектном способе реальную ответственность берут на себя обе стороны, но одна из сторон редко отдает себе в этом отчет.

Способ 3. Рамочный договор о сотрудничестве.
Жизненность этого способа определяется его гибкостью. Если после предварительных 2-4 встреч с руководством (помните, — в начале статьи?) задачи, сроки и, следовательно, стоимость внедрения можно оценить с погрешностью до 40%, то после этапа постановки задачи ситуация определяется с погрешностью до 10%. В зависимости от того, на каком этапе при проектном способе работы принимается решение о проекте, Заказчик рискует «попасть» либо в эти 40, либо в те 10 процентов риска. В отличие от проектного способа стороны констатируют общее видение предполагаемых задач, сроков и стоимости, но фиксируют лишь те задачи и этапы работ, которые им ясны на 100% (принимая на себя двустороннюю ответственность), и договориваются о том, что новые задачи будут формулироваться и выполняться оговоренным способом по мере их прояснения. И так до тех пор, пока окончательная цель не будет достигнута. Меньшая жесткость — меньший риск. Возможность внесения оперативных корректировок гарантирует меньший расход ресурсов (они не тратятся на выполнение ненужной работы), а значит, гарантирует лучшее, по сравнению с проектным способом, соотношение результат/цена.

Чего внедряем?

Все предыдущие статьи были абстрактны до академизма. Рассматривались скользкие места и опасности внедрения как такового, внедрения самого по себе, как сказал бы Киплинг. Предметный же смысл внедрения оставался за рамками — система управления..., бизнес-процессы.... Что такое «управление», и чем бизнес-процесс отличается от, скажем, Нюрнбергского? Плохо то, что эти термины кажутся интуитивно понятными настолько, что мы легко миримся с их полной непонятностью.
А все просто. Итак, процесс управления практически любым объектом можно представить следующим циклом:

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

Оставим пока в стороне вопрос о том, что именно является объектом управления в контексте внедрения. Важно, что автоматизированная система управления в общем случае должна автоматизировать именно этот цикл, так как именно он является определением термина «управление». Вопрос в том, какие фазы управленческого цикла подлежат автоматизации? Достаточно очевидно, что не целеполагание и корректировка, которые пока являются прерогативой человека, поскольку на этих этапах разрабатывается/корректируется миссия, стратегия предприятия, его глобальные планы (имеющие, в основном, качественную оценку) или производится изменение плана — процесс, тоже не подлежащий алгоритмизации. Помочь в этом человеку может только другой (чуть не сказал «человек») консультант. Хорошо, если фирма-внедренец имеет отдел консалтинга, и при необходимости будет готова выделить опытных консультантов по этим вопросам. Формирование управленческого воздействия — процесс волевой в не меньшей степени, чем интеллектуальный. Компьютер тоже ничем не поможет. На всех же остальных стадиях автоматизация весьма и весьма уместна. В любом случае сбои на любой стадии управления приводят к тому, что объект становится плохо или вовсе неуправляемым.

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

Бизнес — это когда деньги

Еще точнее, бизнес — это движение ценностей относительно центров собственности. Иными словами, если вернуться к предыдущему географическому примеру с кораблем, то на бизнес-карте расположены не страны, а собственники, не города, а Центры Финансовой Ответственности, коммуникациям соответствуют денежные и товарные потоки. Сводная информация о начальных остатках, изменении и конечных остатках различных ценностей для ЦФО или собственника за некоторый период называется бюджетом. Нарисованная картина достаточно схематична, но я хочу сказать следующее — при автоматизации любой фазы управления бизнесом необходимо, чтобы внедренец владел всей предметной областью. Знать, как расшифровывается аббревиатура НДС, поверьте, недостаточно, и если внедренец не понимает, чем доходы отличаются от поступлений, то лучше, если он будет что-то там внедрять вашим конкурентам. Внедрение — это, прежде всего, дело экономистов. После короткого лирического отступления переходим к рассмотрению вопросов автоматизации первой из четырех фаз управления бизнесом.

Есть ли у вас план, мистер Фикс?

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

В качестве платформы для автоматизации была выбрана система «1C:Предприятие 7.7», которая, как показывает практика, является самой распространенной среди внедренцев. Для реализации подобной схемы бюджетирования в системе разрабатываются соответствующие бюджетам документы. Важно, что внесение информации в систему по части бюджетов удобно выполнять не через документы (в терминах 1С), а через электронные таблицы, которые разрабатываются в системе «1С: Предприятие 7.7». Естественно, часть данных является расчтными показателями. Для этого в системе разрабатываются соответствующие справочники. Например, на приведенной схеме планирования бюджет закупок получается автоматически из бюджетов продаж, производства, остатков, справочников рецептуры (калькуляции), норм закупок разного сырья у поставщиков, сроков доставки и переработки сырья.
Но мало просто разработать объекты и формы отчетности. Процесс составления планов — есть коллективный процесс работы менеджеров, в течение которого планы обсуждаются, корректируются, утверждаются. Рассмотрим этот процесс на примере планирования постоянных расходов.

1. Финансовый директор делает в системе пометку о начале планирования.
2. Автоматически всем указанным ранее пользователям рассылается сообщение (да-да, как в MS Outlook) о начале планирования следующего периода, его сроках и deadline предоставления плана. Все это в «1С» можно реализовать.
3. IT-менеджер, в числе прочих ответственных, получает указанное сообщение и начинает планировать, допустим, следующий месяц.
4. Он указывает номер декады (недели, точную дату — все зависит от выбранной модели), статью расхода и сумму. При этом заранее составлена проекция менеджеров, участвующих в планировании, на статьи затрат. Это значит, что IT-менеджер никак не сможет планировать налоги или зарплату основного производственного персонала, поскольку ему это запрещено. Но выбрать статью — оргтехника и провести по ней $600 (поддержание и текущий ремонт) он сможет.
5. Завершив планирование, менеджер оценивает свои планы, что-то меняет и ставит отметку.
6. Автоматически система формирует сообщение, что тогда-то такой-то IT-менеджер предоставил все планы.
7. Финансовый директор, таким образом, получает консолидированную информацию от всех отделов.
8. Затем, как правило, полученные планы не удовлетворяют финансового директора (а может — генерального директора или акционеров). Финансовый директор или дает задания подразделениям что-то изменить, или в пределах дозволенного меняет сам. Но с автоматическим предупреждением всех заинтересованных лиц.
9. В результате в системе формируются приемлемые для всех сторон (естественно, с учетом их веса) бюджеты расходов и платежей.
10. Финансовый директор закрывает указанный период для планирования, после чего всем автоматически рассылаются оповещения об утверждении (невозможности дальнейшего изменения) бюджетов.

В результате сформированы четкие планы расходов и выплат предприятия на предстоящий период. На практике процедура разработки и утверждения подобных планов занимает от 3 до 10 дней в зависимости от сложности бизнеса и скорости принятия РЕШЕНИЙ, о которой речь шла в предыдущей статье. Учитывая требования конкретного менеджмента, указанная процедура может быть проще или сложнее. Например, возможно лимитирование определенных статей (в абсолютных величинах или в процентах от других статей) — на рекламу нельзя тратить более 6% всех поступлений от продаж и т.д. Пожалуйста, система усложняется, но продолжает оставаться реализуемой в системе «1С: Предприятие 7.7».

Для большинства предприятий, как показывает практика, вместе с автоматизацией планирования необходима его первоначальная постановка, т.е. разработка схемы и регламента бюджетирования. Хорошо, когда клиент прямо заявляет о своей проблеме в этой области, и готов на помощь со стороны консалтинга: ранняя диагностика — меньше осложнений. А процентов 80, как показывает практика, — нет (то ли не знают, то ли стесняются). Тогда выход один, если внедренец — фирма толковая, гордая, и болеющая за своих клиентов, то в процессе разработки постановки задачи и ТЗ, аккуратно, в необходимом объеме (возможно, без разработки красивых, но часто бестолковых положений) она проведет разработку схем и регламента планирования. Так сказать, окажет «скрытый консалтинг». Но учтите предыдущее лирическое отступление — для этого нужны очень опытные и образованные постановщики.

Почему распадаются социализмы?

Честно говоря, не знаю. Больше того, я вообще не уверен, что они распадаются. Во всяком случае, нашему-то еще жить, да жить, если судить по происходящему.
Какое отношение социализм имеет к проблемам внедрения? Никакого. Просто, вспомнил сакраментальное: «Социализм — это, прежде всего, учет и контроль». А в предыдущей статье мы говорили о некоем цикле управления, в котором, правда, не было фазы «Учет», но и фаз было не две, а больше. А еще говорилось, что если фаз управления меньше, чем должно быть, то объект неуправляем, а значит, врежется наверняка! Вспомнили?

Продолжаем работать, или Сначала был план

В предыдущей статье мы рассмотрели пример автоматизации фазы планирования. Следующая за ней фаза — выполнение. Вернемся к примеру из предыдущей статьи о планировании расходов и выплат. Пришел черед выполнять план — ремонтировать оргтехнику. Алгоритм действий пользователей в КИС (напомню, в качестве платформы была выбрана система «1С:Предприятие 7.7») в рассматриваемом случае был следующим.

1. Подчиненный IT-менеджера (или он сам) должен был ввести в систему заявку на выплату, допустим, $630 (а запланировано было, как вы помните, $600), указать статью — поддержание оргтехники, и способ оплаты — безналичный (тоже бывает).

2. Он сразу же видел перерасход — $30 (в общем случае — величину неизрасходованного остатка по статье). Если он человек мужественный, в системе была возможность послать такую заявку финансовому директору (нажми кнопку «Отправить по маршруту»). Иначе — надо было корректировать сумму выплаты.
Нелишний комментарий. И в случае автоматизации процесса планирования, и сейчас, — без организации документооборота КИС просто ..., ну, непродуктивна, что ли? Для каждого документа, если с ним работает несколько сотрудников в определенной временной и логической последовательности, просто необходимо разработать маршрут. То есть, не обязательно строить КИС на базе системы документооборота типа Notes, но, что по своим возможностям она должна быть круче MS Outlook, — это факт.

3. Финансовый директор получал сообщение о новой заявке от IT-менеджера, видел перерасход по ней и текущий остаток денежных средств на том счете, с которого она будет уплачена.

4. Если финансовый директор был согласен, он утверждал заявку и продолжал ее движение по маршруту. Если не согласен — отклонял, что означало возврат заявки к ее отправителю с указанием причины отвода.

5. В случае утверждения заявка попадала к бухгалтеру, который, после получения необходимых документов (счета, акта, счета-фактуры и т.д.), ставил свою визу — «проведено».

6. Дальше — бухгалтеру по банку, который одним движением на основании заявки печатал платежное поручение. Заявка получала статус — «удовлетворена».
Заметим, что необходимым элементом документооборота является доступность ответственным лицам информации о том, кто и как долго обрабатывал заявку, и в какой стадии она в данный момент находится. Естественно, на практике было много нюансов. Например, если заявка удовлетворяла плану, то этап 3 мог и отсутствовать.
Я специально начал с конкретного примера, дальше я попытаюсь систематизировать сказанное. А сейчас, увы, должен прерваться на внесение терминологической ясности.

Что такое Учет, или Стоит ли говорить о второстепенном?

Мы говорим выполнение, подразумеваем... Что и говорить, термин «учет» пользуется чрезвычайной популярностью. На мой взгляд, он имеет пусть важное, но достаточно подчиненное значение в системе управления предприятием. К сожалению, то исключительное внимание, которое ему уделяет большинство внедренцев, чревато — на практике это означает недооценку других аспектов внедрения КИС. Предупреждаю, глава будет очень скучной и говориться будут вещи ТРИВИАЛЬНЫЕ. Ниже я покажу, что они, действительно, второстепенны, а пока, что делать, — придется потерпеть. Итак, учет бывает бухгалтерским и управленческим.

Бухгалтерский учет — система сбора и хранения информации о хозяйственно-финансовых операциях с целью получения фискальной отчетности.

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

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

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

Каждый первичный документ порождает одну из нескольких бухгалтерских (совокупности проводок) и управленческих операций. Список и содержание этих операций, естественно, подлежат определению и настройке внедренцем и заказчиком перед и в течение опытной эксплуатации. В общем случае, один хозяйственно-финансовый документ может порождать не одну операцию, а цепочку связанных бухгалтерских и управленческих операций. Опять же, совсем не обязательна строгая синхронизация проведения соответствующих бухгалтерских и управленческих операций.
Если после сказанного вы решили, что фаза выполнения планов и «учет» — это синонимы, поздравляю, вы ошиблись. Кроме управленческого и бухгалтерского учета, ведь есть еще и маркетинг, и управление персоналом, и прочая, прочая, прочая... То есть, если строго, учет является лишь фрагментом фазы выполнения, и при автоматизации исключительно его, отдача от вложенных инвестиций в систему будет в несколько раз меньше, чем от инвестиций в создание полноценной АСУ. Все равно, что вкладывать деньги в менее надежный банк под меньший процент.

Строгие определения, это, конечно, хорошо, но какая практика исчерпывающе описывается теорией? Просто перечислю часть того, с чем можно столкнуться на практике в многотрудном деле автоматизации фазы выполнения (давайте, все-таки, отдохнем от «учета») — списком, не раскрывая.

  • Необходимость одновременного ведения разных систем бухучета для одного предприятия (например, хозяйственного, бюджетного, в системе GAAP).
  • Необходимость ведения нескольких «бухгалтерий» одного предприятия (мы имели ввиду холдинг, а вы что подумали?).
  • Национальные особенности управленческого учета: бартер, взаимозачет или расчет закупочных цен и калькуляции производства в зависимости от цен продажи и фирм в составе холдинга, осуществивших реализацию, и т.д.
  • Необходимость стыковки с разнообразным периферийным оборудованием (кассовые аппараты, штрих-кодовое оборудование, АТС и т.д.).
  • Построение территориально-распределенной системы автоматизации.
  • Использование различных программных платформ...
    И ТАК ДАЛЕЕ.

Undo
(Отменить предыдущее)

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


Властелин колец

А теперь о Главном. Если вы обратили внимание, в основе схемы фазы выполнения лежит тот же цикл управления, о котором мы говорили в предыдущей статье. Не надо сильно напрягаться для того, чтобы увидеть старых знакомых — Целеполагание, Планирование, Выполнение, Контроль, Корректировка, Формирование управленческого воздействия. Вы их видите? Парадокс? Да нет же! Любая подсистема управляемой системы должна и может быть УПРАВЛЯЕМА! И коль скоро это так, цикл управления и методы его автоматизации принципиально одинаковы, идет ли речь о предприятии в целом, некоторой области его деятельности (маркетинг, закупка/продажа, производство, управление персоналом и т.д.) или конкретных бизнес-процессах, являющихся частью областей деятельности.

Если перенестись в мир геометрических аллегорий, то цикл управления является типичным фракталом — регулярным геометрическим элементом, часть или части которого могут в свою очередь являться исходным элементом, представляя собой зримый образ рекурсии. Узоров, являющихся комбинациями циклов-колец, бесконечно много, и каждый конкретный узор может являться интерпретацией/описанием системы управления неким РЕАЛЬНЫМ объектом/предприятием. Или, наоборот, любое управляемое предприятие является просто интерпретацией какого-то переплетения колец. Совершенный узор — совершенная система управления — совершенное предприятие. Любой изъян в узоре означает СОВЕРШЕННО РЕАЛЬНЫЕ ПРОБЛЕМЫ в этой жизни.

Фаза контроля

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

Фаза анализа

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

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

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

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

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

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

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

Было решено ввести еще один этап (между этапами 2 и 3). Этим новым звеном стал этап Согласования. Появились две новые должности:

1) менеджер, отвечающий за согласование отклонений с поставщиком. Он несет ответственность за то, что поступит именно согласованный товар; 2) менеджер, отвечающий за то, что согласованный товар будет востребован и продан филиалом.

И, представьте, одного этого оказалось достаточно для существенного сокращения потерь!

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

Что такое AQ, или какая КИС умнее?

Очень простой вопрос — для чего вообще нужна автоматизация? То есть для того, чтобы функционировала система управления, совсем не обязательны ПК. Они и появились-то совсем недавно, а сколько лет бизнесу — никто не знает. Иными словами, ПК действительно необходимы только для игры в Quake, а бизнес, и тому масса примеров, может без них обойтись. (Это, вообще, очень интересная задача — обоснование очевидных вещей). Ну, ладно, не буду томить: на простой вопрос — простой ответ. Автоматизация нужна для повышения эффективности бизнеса. Каким образом? А смотрите, допустим, существует сотрудник, должностные обязанности которого достаточно формализованы (регламентированы). Если они не сложны и нагрузка не велика, то нет проблем. Но что происходит на практике при увеличении нагрузки, причем нагрузка здесь — не обязательно в увеличении операций, это может быть повышение цены принимаемых решений, нервная нагрузка и прочие факторы. А происходит то, что количество выполняемых за единицу времени производственных операций уменьшается, зато вероятность технологических ошибок увеличивается. Поэтому замена алгоритмизируемых человеческих операций на машинные совершенно формально приводит к увеличению эффективности и надежности всей системы. И именно в этом и состоит задача автоматизации. Из этого же следует критерий оценки КИС как автоматизированной системы:

Коэффициент автоматизации (AQ) обратно пропорционален кол-ву алгоритмизируемых, но не автоматизированных операций.

Т.е. чем больше осталось ручной, рутинной (напомню, routine — по-английски — программа) работы, тем он ниже.

Плохо автоматизированная система (в вышеуказанном смысле) в предельном случае является просто хранилищем данных, в которое кто угодно, или что угодно просто вводит данные, потом эти данные, как правило, массой выбрасываются пользователю, который волен поступать с ними, как хочет. (Справка: хранилище с регламентированным вводом, но не регламентированной выборкой, на русском языке называется «свалкой»).

Пример 1. Опасность недоавтоматизации. На некотором предприятии в системе была реализована поддержка планов, учета, планирования, и контроля. Вроде бы хорошо. В числе прочих составлялся бюджет выплат. Но на самом деле учет выполнения планов велся без предварительного контроля, т. е. при плане выплат в 100 единиц сотрудник мог сделать платеж на 500, и на следующий день менеджер видел результаты контроля — отклонение — 400. Правда, было уже поздно, так как отменить действие было невозможно. Поэтому перед любым платежом сотруднику приходилось сопоставлять план выплат, уже произведенные выплаты и намеченную выплату, а хранились они в разных подсистемах и т.д. и т.п. = время, раздражение, ошибки. А достаточно было просто проработать механизм лимитирования, и при попытке превышения лимита оператор получал бы соответствующее уведомление и рекомендацию отправить заявку на согласование и утверждение. Т.е. система с необходимой степенью гибкости реагировала бы, и больше того, даже регламентировала бы деятельность оператора. Т.е. коэффициент автоматизации — это IQ КИС.

Но существует и другая опасность.

Пример 2. Опасность переавтоматизации. Предприятие купило престижную КИС (западного производства), вложив в нее сотни тысяч долларов. Номенклатура товаров — около 10 000, поставок — до 500 в день. Так вот, вместо обычных кладовщиков предприятие вынуждено было взять на работу квалифицированных программистов (хорошо, склад в Санкт-Петербурге, а не где-нибудь в провинции) для ввода накладных и подготовки отчетности. А все потому, что в этой КИС товар представлялся двенадцатизначным кодом, и пользователю каждый раз требовалось набирать в документах эти цифры, специальным образом ежедневно расшифровывать из данных штрих кодового оборудования, копировать и импортировать файлы, и снова преобразовывать коды в отчетах. А любая ошибка или несвоевременное выполнение операций, приводили к серьезным проблемам. То есть оперативность и достоверность информации, которую предоставляла КИС, зависела от такого числа человеческих факторов, что сбои были, фактически, запланированы.

Один интересный вывод, подчеркивающий близость IQ и AQ. Знаменитый закон Тейлора гласит: «Из двух кандидатов, одинаково пригодных для работы, следует выбрать более глупого». То же и с КИС — из двух КИС, одинаково пригодных для автоматизации вашего предприятия, следует выбрать ту, у которой AQ ниже (более глупую). По крайней мере, денег сэкономите.

Трехмерное пространство КИС

А теперь итог. Приведу определение КИС — это автоматизированная система сбора, хранения, обработки и предоставления информации для целей управления предприятием. Выделим главное:

1. Для чего нужна КИС — для УПРАВЛЕНИЯ
2. УПРАВЛЕНИЕ чем — ПРЕДПРИЯТИЕМ
3. УПРАВЛЕНИЯ какого — АВТОМАТИЗИРОВАННОГО

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

Предприятие, как объект управления, имеет свою специфику. Во-первых, накладывается ограничение на количество автоматизируемых фаз цикла управления (в отличие от управления крылатой ракетой в бизнесе целеполагание, корректировка и управленческое решение не автоматизируются, по крайней мере, пока). Во-вторых, предприятие имеет функциональную иерархическую структуру, — существуют сферы деятельности (продажи, закупки, производство, маркетинг и прочее), каждая из которых состоит из бизнес-процессов. Система управления может существовать, как для всего предприятия, так и затрагивать только его функциональные фрагменты — сферы деятельности и бизнес-процессы. Системы управления можно классифицировать по тому, какими и сколькими фрагментами предприятия они «управляют».

Что такое автоматизация, мы говорили в начале статьи. Системы управления можно классифицировать по значению коэффициента автоматизации AQ.

Не заблудиться бы в пространстве КИС

Как пользоваться критериями для определения оптимальной (той, что нужна именно вам) КИС? Наш опыт показывает, что в пространстве КИС правила «лучше больше» или «лучше меньше» не работают. Необходимо точное определение координат системы управления (того, что нужно). Построение КИС с максимально близкими, по возможности (на практике совпадение бывает очень редко), координатами.

 

К сожалению, большинство предприятий в пространстве КИС находятся вблизи «абсолютного нуля», и, абсолютно, все предприятия хотят находиться по диагонали от него, и как можно дальше. Проблема заключается в том, что сделать это в один присест, да еще само собой, не удастся. В современной русской управленческой психологии, ярчайшим представителем которой является Владимир Тарасов, есть такой принцип — «путь из беспорядка в «полный порядок» лежит через упрощенный порядок». Следствием этого является то, что невозможно из «абсолютного нуля» (беспорядка) сразу перейти куда-то далеко по диагонали (полный порядок). Следовательно, любая попытка мгновенного и легкого достижения полного порядка не научна или, по-простому, обречена. Но после каждого частичного улучшения, устраняющего частицу беспорядка, необходимо ставить конкретную ДОСТИЖИМУЮ цель, приближающую к порядку. «Навигирование» в этом пространстве имеет свою специфику и безопасно (без неприятных последствий разного рода) в нем перемещаться можно, только используя специальную методику.

Гуд бай, Эмерика...

Вся новейшая история России в сильной степени определена (может, лучше «омрачена»?) влиянием различных экономических учений. Именно экономические концепции являлись фундаментом политики и идеологии. И сами концепции, и результаты попыток их реализации были различными. Но практически всегда теории имели brand «made in ...». Оставим в стороне вопросы отражения экономических теорий в политике и идеологии. Да и сами экономические теории тоже оставим в стороне.

Рассмотрим более узкий вопрос: насколько применимы методы осуществления экономической деятельности, хорошо зарекомендовавшие себя в одной культурной (ведь экономика — это часть культуры) среде при переносе в другую? Проще говоря, годится ли западная методика управления предприятием в России? Предлагаем эксперимент — опросите окружающих вас менеджеров и специалистов по информационным технологиям, что такое MRP и его «апгрейды» MRP II и ERP? Только честно, и не только на своем предприятии, а и среди знакомых. Соотношение числа ответивших и не ответивших будет ответом. Незнание английского от ответственности не освобождает. Что такое Pentium, Windows и management знают все. Повторяем, речь идет не о том, на многих ли предприятиях внедрены западные системы и методики управления предприятием (вопрос цены сразу оставляем в стороне), а о том, много ли более или менее успешных менеджеров вообще поймут, о чем вы говорите? Ребята, давайте посмотрим правде в глаза — после 10 (2 университетских образования!) лет, в течение которых нам это пропагандировали и даже пытались внедрять, по-прежнему страшно далеко все это от народа. Как спросил бы Маяковский: «Послушайте, если об ERP не знают, может это никому не нужно?».

Наша российская несообразительность — объяснение не остроумное. Уверяем вас, встречаются очень даже сообразительные. И даже такие, которые тесно сотрудничают с тем же Западом в бизнесе. А все равно не знают и, более того, не стремятся. Что, впрочем, не мешает им контролировать существенную долю своего рынка. Вывод простой — наши миры, Россия и Запад, в настоящее время параллельны друг другу. По крайней мере, в этой области.

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

Давайте говорить по-русски

Почему западная технология управления предприятием не приживается в России? Потому что условия совсем другие. Несмотря на свою динамичность, бизнес на Западе развивается по довольно жестким законам, частью писаным, частью неписаным, но сами эти законы меняются относительно редко и по определенному регламенту. Все, в общем, прогнозируемо. Поэтому вопрос комплексного управления предприятием именно как единого целого с одной стороны, а с другой охватывающего все участки его деятельности, может быть решен достаточно успешно. Условия же нашего бизнеса — неопределенность и сплошные факторы, которые надо учитывать. Писаные законы с одной стороны еще более невменяемы, чем неписаные, а с другой — еще и меняются с регулярностью здорового женского организма. Все это приводит к тому, что кроме слов, одинаково понимаемых на разных языках, есть слова вроде бы общие, но означающие вещи разные. Пример? Пожалуйста, — вы уверены, что русские слова «взаиморасчеты» и «налогообложение» при переводе на английский по своей сути будут значить то же самое? Навряд ли. В этом все и дело — западные технологии ориентированы на решение проблем, большинство из которых похожи на наши только по названию, а не по сути.

Решение просто. Не надо придумывать сущностей сверх существующих. Такие понятия, как планирование и бюджетное управление хорошо знакомы России еще с советских времен. И если быть честными, проблема нашего менеджмента не в том, что он без ERP, а в том, что культура именно планирования и бюджетного управления (с которой ERP, собственно, и должно начинаться) за последние годы сильно коррозировала. С планирования и бюджетного управления, вернее, с их восстановления и нужно начинать. Остальное только после этого. Помните, что методичность и постепенность —это то, чем образование отличается от самообучения. Предупреждаем, односторонних специалистов, как и флюс, приходится потом долго «лечить».
Давайте вспомним:

 

Идемте с нами

Итак, всем нам нужны массовые качественные технологичные системы планирования.
Массовые — значит понятные подавляющему большинству действующих менеджеров. Для начала нужно безусловно, и тотально использовать в работе привычные финансовые показатели. Старые добрые бюджеты доходов и расходов (БДР) и движения денежных средств (БДДС).
Качественные — значит дающие результаты, подлежащие вменяемой оценке. Должна быть возможность отслеживания менеджером того, какое влияние имеет конкретная хозяйственная операция, отразившаяся в конкретном документе учетной системы, на достижение или недостижение плановых показателей. Без этого невозможен осмысленный контроль достижения плана и план-фактный финансово-экономический анализ по результатам периода.
Технологичные — значит должна быть отчуждаемая, передаваемая менеджерам, методология экспресс-постановки систем бюджетного управления. Что это значит? Во-первых, должна быть возможность адаптации системы планирования для нужд конкретного предприятия. Во-вторых, система должна позволять распределенную работу в том смысле, что на реальных предприятиях в контур планирования может быть вовлечен не один менеджер. А значит, система должна поддерживать политику разграничения ответственности и прав. Кроме того, необходимость кооперации обязательно требует поддержки документооборота. В-третьих, должна существовать возможность всему этому научиться.

Давайте забудем слово «массовые». «Демократичные» звучит лучше (хотя в буквальном смысле это почти то же самое). Демократичность решения должна проявляться и в демократичности требований к оборудованию и ПО. Причем, по российским меркам. (А то недавно «пронеслось» — западные коммерческие банки в России снизили порог валютных вкладов физических лиц до $1000 — интересно, о чем думали раньше? Наверное, грезили о своих соотечественниках). Ведь, кроме всего прочего, западные системы даже по критерию стоимости являются элитарными.

Вверх

<<Назад

Главная| ИС.. | Моделирование | Проектирование | ТЗ | Разработка | Интерфейс | Статьи | Ссылки | Автор
DimDim SoftWare Мастерская Dr. dimdim Copyright 2003-2004
Администратор info-system@mail.ru
Последнее обновление 26-Дек-2003