КИС’кин дом
Сага о корпоративных информационных системах и их пользователях
Елена Монахова, Игорь Альтшулер
Том 2. Часть 3. Мы не АСУ’шники, мы информационные снабженцы
Эта часть саги - наш первый вклад в копилку рассказов о роли ИТ-менеджеров в крупных компаниях, сделанный по многочисленным просьбам читателей. Своими впечатлениями о тернистом пути информационных технологий на предприятия автомобильной промышленности, пролегающем через конфликты с высшим руководством, саботаж на местах и прочие прелести внедрения крупной ИС, делится директор Центра информационных технологий инжиниринговой компании “Промышленные и компьютерные технологии” (Нижний Новгород) Лев Павлов.
В течение последних шести лет он был сначала начальником отдела автоматизации, а затем заместителем генерального директора по автоматизации ГАЗ АТО - одной из крупнейших структур в системе Горьковского автозавода, которая занималась автотехобслуживанием и продажей автомобилей на всей территории СНГ. В лучшие времена (в 1993 - 1994 гг.) в эту структуру входило 175 специализированных предприятий и оборот ее достигал нескольких миллиардов рублей в день. Итак, слово Льву Павлову.
Право на “революцию”
Задача перед нами была сформулирована руководством в самом общем виде: “Надо сделать единую информационную систему”. Какую, на чем - никто не уточнял. Поездив по таким фирмам, как БМВ, “Форд”, “Фольксваген”, дирекция ГАЗ АТО хотела, чтобы и у нас появилось что-то подобное. Поскольку подробной документации и описания своих систем ни немцы, ни американцы гостям почему-то не дарили, то общее впечатление у нашего руководства было, а понимания того, что же нужно сделать, - не было. Мы внимательно изучили российский опыт (в том числе передового в ту пору ВАЗа) и пришли к выводу, что стандартных решений, которые мы могли бы использовать у себя, нет.
Надо сказать, что в течение двух лет высшее руководство неизменно оказывало нам поддержку - и финансовую, и организационную, дав все необходимые полномочия для претворения наших решений в жизнь. Фактически нам было дано право “совершить революцию” на фирме, что мы вскоре и сделали в самом сложном отделе материально-технического обеспечения. Сложность там заключалась не только в широте ассортимента, но и в том, что коллектив отдела сложился в советские времена в условиях дефицита распределяемых запчастей и перестраиваться не собирался.
Мы начали с того, что выбрали надежную перспективную основу - СУБД Oracle. Сегодня это решение кажется очевидным, но в 1992 г. оно натолкнулось на глухое непонимание многих коллег (даже на самом ГАЗе). Затем определили общую стратегию, выделили три главных проекта: “Центр”, “Дилер” и “Связь”. Пройдя большую школу на автозаводе (не один год занимаясь внедрением систем автоматизации цехового уровня), мы понимали, что нельзя строить то, что еще не запроектировано, и потому вначале система рождалась на бумаге. Вместе с тем я не верю тем, кто с самого начала рисует детальные проекты, тратит кучу времени и денег: ведь большая система начинает оживать только во время опытной эксплуатации. Американцы даже говорят: “Проектирование системы начинается после ее разработки”.
Мне думается, что очень важно начать с определения основных бизнес-процессов и информационных структур, которые будут эти процессы обеспечивать. Нужно “почувствовать” объект - ведь созданная информационная система станет потом основой функционирования и развития предприятия, одним из ключевых его ресурсов. Термина “бизнес-процессы” в те годы еще не было, но процессы (такие, как обработка заказов на получение запчастей, выдача клиенту товара со склада, “обеспечение гарантийных запасов на складах”) мы моделировали и даже проводили деловые игры с руководителями предприятий и служб, чтобы отработать схему взаимодействия подразделений и получить целостную картину функционирования всего предприятия.
Были разработаны простые модели и на их основе написаны программы (как раз это-то не проблема). В результате количество рабочих мест в отделе материально-технического обеспечения сократилось с 18 до 3, а клиент вместо 1 - 2-дневного блуждания по 8 кабинетам с коробками конфет и иными знаками внимания стал получать то, что положено, в одном месте за полчаса. При этом удалось связать материальные и финансовые потоки: одновременно оформлялись отпускные документы, доверенности, автоматически выполнялись соответствующие бухгалтерские проводки. Сейчас я думаю, что задачу эту мы смогли решить только благодаря полной поддержке высшего руководства, давшего нам карт-бланш. Никакие мягкие и постепенные схемы внедрения в таких подразделениях, как склады, к успеху не приводят, а вот в бухгалтерии вполне возможен эволюционный путь: мы автоматизировали один участок за другим вплоть до получения полного баланса.
Два года, как я уже сказал, мне было отведено на “инкубационный период”, именно в это время кривая наших внедрений резко шла вверх, и именно тогда был сделан основной объем работ. Но милость монархов не бывает вечной, поэтому следующие три года стали годами непрерывной борьбы за место под солнцем, что никак не способствовало успешной деятельности (хотя к этому времени у нас уже появился реальный опыт работы не только в стенах одного предприятия, но и в масштабах страны, и мы овладели новыми технологиями). Пришлось, например, пройти через типичный для многих предприятий конфликт между главным бухгалтером и ИТ-менеджером. Такие конфликты характерны для тех предприятий, где роль главного бухгалтера завышена, а финансового директора либо нет, либо он играет второстепенную роль. (Кстати, о подобных ситуациях на предприятиях, где финансисты имеют реальную власть, я что-то не слышал.)
Все очень просто: планы, проекты, люди
ИТ-менеджер, автоматизирующий бизнес-процессы, зачастую знает свое предприятие глубже других руководителей, известны случаи, когда на Западе ИТ-менеджеры со временем становились первыми лицами компаний. У нас же отделы АСУ традиционно были второстепенными, вспомогательными службами и их начальники крайне редко входили в состав высшего руководства предприятия. Лично мне повезло: меня через два года работы включили в состав правления фирмы, таким образом, я смог не только получать всю информацию из первых рук, но и участвовать в подготовке и принятии важнейших решений. В 1995 г., например, мы провели акцию “Стратегическое планирование” с привлечением внешних консультантов.
Оказалось, что даже миссию предприятия члены правления смогли внятно сформулировать лишь через неделю. Сама процедура стратегического планирования быстро начала выявлять, “кто есть кто”, и демонстрировать степень готовности предприятия в целом и отдельных людей к работе в рыночных условиях. Поэтому для правильного построения информационной системы просто необходимо такие акции повторять, лучше ежегодно.
И надо освобождаться от плена популярных книжек и распространенных предрассудков и шаблонов типа: “Мы работаем для конечного клиента”. Многие подразделения работают друг на друга, это надо учитывать. ИТ-менеджеру не пристало претендовать на какую-то исключительность, он должен понимать, что внедрение (и даже разработка) информационной системы - это обычный проект, которому нужны бюджет и сметы и управлять которым нужно с точки зрения науки, именуемой финансовым менеджментом. Анализ издержек в различных разрезах, в том числе по центрам и объектам затрат, - это и есть одна из основных задач ИТ-менеджера.
Другая его важнейшая задача - обеспечение хорошего психологического климата как внутри своей службы, так и при ее взаимодействии с партнерами и пользователями. Я для себя сделал глобальный вывод: нельзя оставлять без внимания мелочи; если есть маленький “прыщик”, он обязательно разовьется и рано или поздно превратится в гнойный нарыв. Пример: человек, которого мы обучили, которому дали хорошую технику, инструментарий, счел разработанную программу своей собственностью и попытался продать ее “на сторону” (еще и по дешевке). Когда ты вмешиваешься в такой процесс, нужно разобраться, осознал человек свою ошибку или только делает вид. В последнем случае надо с ним немедленно расставаться - потому что человеческие качества для работы в коллективе (к тому же в экстремальных режимах) более важны, чем профессиональные.
Как там классик говорил? Учиться, учиться и еще раз учиться!
ИТ-менеджер не имеет права вариться в собственном соку, я, например, даже в самые трудные времена находил время, чтобы читать монографии по составлению бюджета или книги Д. Васкевича типа “Стратегии клиент-сервер”. Посещение выставок, семинаров, участие в конференциях, чтение периодики дает необходимый кругозор, который ИТ-менеджер просто обязан иметь. Лично я избрал для себя простой способ получения информации: изучение опыта лидеров в своей области. Как в штаб-квартире Форда всегда стоит последняя модель Тойоты (чтобы народ “не зевал” и не расслаблялся), так и на моем рабочем столе всегда лежали материалы с описанием систем - мировых лидеров в области построения информационных систем. Зная, как развиваются они, можно было делать собственные выводы (с учетом того, что российская специфика кое-что позволяет сделать проще, а кое-чего не позволяет сделать вообще).
Иногда бьешься лбом об стенку из-за того, что сроки срываются, ругаешь своих программистов, клянешь клиентов. А потом изучаешь мировой опыт и выясняешь, что это нормально. Просто надо было все это предусмотреть, спланировать, и деньги с клиента за внедрение взять такие, и сроки согласовать такие, чтобы не ставить перед собой заведомо невыполнимых задач. В этой ситуации роль быстрого проектирования или быстрой настройки, которой так гордятся некоторые разработчики, уже не столь важна, потому что все эти красивые рекламно-презентационные моменты лишь плодят лишние иллюзии, но не слишком существенно влияют на общий срок создания и внедрения системы и перехода к реальной ее промышленной эксплуатации.
Впрочем, учиться должны не только ИТ-менеджеры. Высшим менеджерам предприятия это тоже не помешает. Тогда они смогут точнее формулировать задачи и предъявлять более четкие требования к ИТ-менеджеру (как, впрочем, и к другим сотрудникам). Если ИТ-менеджер не справляется с задачей, то, может быть, его и пора менять, но возможно, что его надо активно поддерживать и направлять, - другие решения могут привести не только к убыткам, но и к разорению фирмы.
Информационные снабженцы
Чтобы система удовлетворяла потребности высшего руководства, нужно создать не АСУ, а именно информационную систему, снабжающую руководство информацией для выработки управляющих воздействий. Мы ничем не управляем, управляет пряник или кулак руководителя при соприкосновении с его же столом. Мы лишь даем информацию о том, почему то или иное подразделение, возглавляемое конкретным лицом, не обеспечило запланированную норму прибыли или превысило издержки.
Проектирование корпоративной системы должно идти “сверху”, от рабочего места высшего руководителя (мы сначала анализируем, что ему нужно или может понадобиться), а вот внедрение, по-моему, должно идти “снизу вверх”, потому что оперативная первичная информация возникает внизу, ее надо “ловить” на месте и в момент ее возникновения, а потом уже собирать, фильтровать, агрегировать и анализировать. При этом мы не ставим своей целью облегчение труда (в отдельных случаях трудоемкость может даже возрастать) или повышение эффективности работы конкретных клерков. Юристы должны обязательно регистрировать все договоры не потому, что это для них удобнее, а потому, что эта информация нужна многим другим подразделениям.
И пора уже прекратить споры о том, что лучше - внедрение готовых систем или разработка собственных. Вы в своем еженедельнике постоянно упоминаете 5, от силы 10 зарубежных систем, а ведь их там тысячи. Поэтому не надо бояться разрабатывать и внедрять свои продукты, не нужно нам советское единообразие во всем. Существует же множество моделей автомобилей в каждой стране, и все находят свой рынок. Если у вас есть нормальная команда разработчиков, если вы улавливаете мировые тенденции, хорошо знаете потребности определенной ниши рынка, владеете современными технологиями и инструментарием, почему бы не взяться за собственную разработку? Важно только перед созданием системы четко сформулировать цели и условия ее эксплуатации, оценить сроки и стоимость ее создания.
Всем ли нужен “интеллект”-уровень?
Обычно принято считать, что у корпоративной системы есть два основных блока: OLTP, обеспечивающий операционный уровень функционирования предприятия (проще говоря, оперативный учет) и OLAP, обеспечивающий анализ состояния. Я же всегда выделяю в системах еще один блок под условным названием SMART (интеллект) - те наукоемкие алгоритмы, которые позволяют системе решать действительно сложные, неподвластные человеку задачи. У мировых лидеров, таких, как SAP или BAAN, скупающих научные разработки, именно этот SMART-блок обеспечивает основное конкурентное преимущество. Если OLTP и даже OLAP-блок можно реализовать своими силами, то для создания уникального SMART-блока нужна уникальная научная команда. Вместе с тем для большинства отечественных предприятий, автоматизаторы которых любят порассуждать о высоких материях, внедрение даже OLTP и примитивного OLAP-блока может дать достаточно информации для выживания предприятия в условиях сегодняшнего и завтрашнего рынка.
Универсальность нужна поставщику информационной системы для снижения издержек на ее разработку и внедрение. Конкретный же клиент нуждается в решении своих конкретных проблем и не имеет ни малейшего желания оплачивать ненужную ему универсальность и не востребованный им интеллект системы. Поэтому на Западе поставщиков заказных систем сотни, а то и тысячи, думаю, что и у нас их со временем будет не меньше.
Не надо “как есть”, надо “как надо”
Сегодня у нас вызрела собственная методика прямого реинжиниринга. Многие консалтинговые группы предлагают сначала создать модели “того, что есть”, проанализировать их, затем создать модели “как надо” или “как хочу” и описать процесс поэтапного перехода от “как есть” к “как надо”. На бумаге получается красиво, в жизни же мы пришли к выводу, что существующие бизнес-процессы, наслоившиеся за годы работы предприятия, имеет смысл моделировать, анализировать и оптимизировать, тратя на это время и деньги, только в том случае, когда предприятие и без того работает неплохо, но руководитель хочет повысить эффективность процентов на 10 - 20.
Если же предприятие в кризисе и нуждается в радикальной перестройке, изучать его историю нет смысла, нужно проанализировать внешний документооборот, построить цепочки бизнес-процессов, обрабатывающих документы, и на этой основе создать прототип информационной системы. Далее прототип системы демонстрируется руководителю и с помощью привлеченных консультантов разрабатываются процедуры внедрения. Кстати, в ходе этого внедрения могут исчезнуть не только отдельные рабочие места, но и целые подразделения и отделы, существовавшие только потому, что “так сложилось”.
Продолжение следует
Том 1. Часть 1 - см. PC Week/RE, № /97, с. 59. Том 1. Часть 2 - № /97, с. 60. Том 1. Часть 3 - № /97, c. 64. Том 1. Часть 4 - № /97, c. 47. Том 1. Часть 5 - № /97, c. 50. Том 1. Часть 6 - № /97, с. 56. Том 2. Часть 1 - № /98, с. 62. Том 2. Часть 2 - № /98, с. 41.
