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

В беседе принимали участие: Алексей Цицин, генеральный директор фирмы "Термика"; Евгений Ким, директор Центра исследований и проектирования ООО СЕПТ; Дмитрий Соколов, зам. директора Центра экономических исследований "Бизнес-Программы-Сервис"; Борис Вольфман, руководитель отдела системного анализа и проектирования фирмы "ЭЛКО технологии" и ранее представленные в рубрике "Директору" Павел Христов, главный редактор Computerworld Россия; Евгений Зиндер, директор аналитического и конструкторского бюро "Группа 24" и координатор рубрики "Директору ИС", а также научные редакторы еженедельника Татьяна Грачева и Михаил Зырянов.

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

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

Несколько минут было уделено "Управлению'98", где участники клуба договорились о встрече. Эта "разминка" была тем более интересна, что фирма "Термика", выпускающая компакт-диски с материалами выставки-конференции, часть информации - включая доклады конференции - отражает в Internet, и уже пошли отклики. Затем собеседники перешли к "плановым" темам.

Что действительно надо предприятиям?

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

Дмитрий Соколов (ДС): Есть две категории заказчиков: коммерческие структуры живущие на свои деньги, и те, кто живет на бюджетные деньги, то есть на чужие. Это и определяет то, что им надо от автоматизации. Первые хотят, чтобы им были предоставлены инструменты, с помощью которых они могут развивать свой бизнес. А бюджетному заказчику нужно потратиться, то есть "освоить" деньги. Кстати, противопоставленность и изолированность выставки и конференции на "Управлении'98" напоминают такое положение. На конференции - бюджет государства, на выставке - коммерческие фирмы.

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

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

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

Евгений Зиндер (ЕЗ): Мы почти все время говорим о простейших учетно-отчетных системах. Например - слежение за складом, чтобы воровства не было. Иными словами, предполагается, что цель руководителя, который внедряет ИС, - сделать свой собственный бизнес прозрачным для себя. И за счет этого уменьшить накладные расходы, пресечь воровство. Но дело все еще не доходит до работы с динамичными целями управления, в том числе связанными с конкуренцией. Пока речь идет о достаточно примитивных компонентах управления.

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

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

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

БВ: А разве вопрос в том, чтобы решать за руководителя, что ему нужно?

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

Здесь все согласились, что автоматизация - не самоцель и что это может быть принято в качестве аксиомы.

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

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

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

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

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

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

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

Неудачные проекты: причины разные, но понятные

АЦ: Вот случай из практики, который надолго отвратил меня от комплексной автоматизации крупных объектов. Это было на известковом комбинате в одной из центральных областей России. Представьте: в городке - 8 тыс. жителей, на них всех - три компьютера ХТ. Но была - редкий случай - воля руководителя предприятия, генерального директора. Мы выполнили консалтинговые работы, в результате которых выяснилось, что несколько отделов надо сократить, но сократить нельзя. Одна из причин: они - держатели пакетов акций предприятия.

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

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

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

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

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

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

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

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

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

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

Была затронута еще одна причина неудачных проектов ИС - отсутствие обоснованных экспертных оценок приложений.

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

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

ЕК: Адаптивность системы определяется тем, какой диапазон вариации приложений эта система способна "закрыть".

ДС: Факторов, связанных с выбором прикладной системы, очень много. Можно выбрать два подхода - либо детализировать проблему, либо отказаться от детализации вообще, то есть решать ее качественно. Можно положиться на репутацию фирмы [доверяясь ей в вопросе будущего приспособления системы], а можно - ориентироваться на знание ее конкретных продуктов. Главное, чтобы не было серединки.

ЕЗ: Число факторов, которые надо оценить, огромно как со стороны выбираемого приложения, так и со стороны выбирающего предприятия. В идеале все они должны сойтись. Поскольку этого не бывает, с какого-то момента в выборе неизбежны субъективные, "вкусовые" моменты.

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

ПХ: Может быть, переместим разговор чуть в сторону ИТ? Скажите, были ли у вас примеры, когда к неудачам приводил неудачный выбор платформы и из-за этого система не обладала нужными характеристиками? То есть в начале проектирования уже была заложена какая-либо технологическая ошибка?

Мой вопрос связан с историей "Открытых систем". Лет восемь назад мы занимались ОС Unix. Но постепенно поняли, что страна полностью заполнена персоналками, и даже языка, на котором мы пытались общаться, люди не понимают. В результате был придуман журнал с условным названием "За пределами мира ПК", получивший затем имя "Открытые системы". То есть мы пытались активно предлагать всем платформу, которая и сейчас кажется нам очень важной.

Эта часть разговора была на удивление "бесконфликтной".

ЕЗ: Я вспомнил давний проект персональной системы класса RP/RAD. Была выбрана платформа MS-DOS, а не только появившаяся у нас Windows. Планировалось завершить разработку в конце 1991 года, однако по внешним для проекта причинам он задержался на год. Распространение Windows v.2 и v.3, рост памяти PC сделали к началу 1993 года бессмысленными траты на продвижение этого продукта, хотя авторами система успешно использовалась в коммерческих проектах и можно считать, что инвестиции окупились. Трагизм примера в том, что разработчики знали о временности решения, но были вынуждены своими же руками загонять проект в зону высокого риска.

ДС: Я бы обратил внимание на то, как производился выбор платформ для хорошо определенных задач, например так называемых спецвычислений или оптимизационных задач. Здесь отлично работает здоровый инженерный подход. Важна производительность, память, надежность, а не рыночные аспекты выбора ОС или СУБД. Правда, и здесь надо прогнозировать рост объемов данных и требований к скорости их обработки.

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

Парадокс вполне успешного проекта

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

Был затронут и вопрос об оценке проекта по его окупаемости. Обсуждение было коротким, но очень бурным. Собравшиеся признали такую оценку самой проблематичной, хотя, может быть, и самой важной. Прозвучало слово ТЭО - технико-экономическое обоснование. Здесь снова обнаружился эффект дискредитации. Многолетняя профанация ТЭО в прежнее время привела к дискредитации идеи. Интересно, что, когда ТЭО возвращается к нам под названием CBA (cost-benefit analysis), отношение к нему становится серьезней, но подозрение в неизбежности профанации остается.

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

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

О чем стоит говорить

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

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

Приглашаем читателей к участию в клубе - как в "лично-физической", так и в "почтовой" форме. Присылайте вопросы и пожелания по адресу cwr@osp.ru, для рубрики "ДИРЕКТОРУ".