На АСУ надейся, а сам не плошай!

Заметки, которые предлагаются на этой странице, написаны в период с 2004 по 2008 год и посвящены анализу современного состояния вопросов по организации разработок АСУ на небольших частных и преимущественно торговых предприятиях. Первоначальная версия заметок была выложена в виде doc-файлов, для доступа к которым на компьютере пользователя требовался Ms Word. Представляемая HTML-версия заметок является вторым их изданием, существенно отличающимся от первоначальной doc-версии по содержанию.

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

Посетителю и читателю заметок

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

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

Я отчетливо осознаю, что моя писанина не может нравиться всем. Более того, кому-то мои материалы могут не нравиться активно. Но у меня не было цели досадить кому бы то ни было. Бессмысленной цели поплакаться в жилетку, что в закрытом, что в открытом пространстве, я также не имел. Единственное, чего я боюсь, - не получилось ли у меня слишком занудно. Для самоусовершенствования, казалось бы, желательно получить, как реакцию, конструктивную критику. Но в моем случае, кажется, пора менять приоритеты – возраст берет свое, здоровье и силы уходят очень быстро, и, в связи с этим, падает интерес ко многому и к чужому мнению тоже. Будем считать, что я просто делюсь наблюдениями и мыслями, а главное - опытом. Удачно делюсь или неудачно – судить Вам.

• Введение
  
  
• Взгляды пожилого программиста
  
  
• О кондициях АСУ
  
  
• Главный автоматизатор
  
  
• О мотивации
  
  
• Главный руководитель
  
  
• Заключение
  

Заметки между делом

Введение

Если ничего не делать или делать все плохо, то что?

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

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

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

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

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

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

Но заметки содержали много сносок, и по этой причине пришлось их представлять в виде doc-файлов, для просмотра которых на компьютере пользователя требуется MS Word. Механический и рутинный перевод записок в HTML трудоемок и не повышает их качества. Поэтому было ясно, что перевод в HTML, если и делать, то только после принципиальной корректировки содержания. Когда решение об этом было принято, я закрыл доступ к странице сайта, объявив, что страница находится на реконструкции.

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

Я однажды еще в советское время прочитал в какой-то центральной газете заметку редактора. Он довольно обстоятельно отвечал на вопрос читателя. Вопрос был такой: «Почему бы нам в стране не производить много мяса?». Я не рассчитываю, что от меня ожидают ответа на схожий вопрос о том, почему бы нам на фирме не сделать хорошую АСУ. Я предполагаю, что Вы не наивный новичок в «делах асушных», и представляете себе сложность вопроса и стоимость затрат на АСУ. В такой сложной и запущенной ситуации, в какой сейчас очутились многие предприятия, предложить единый набор спасительных рецептов невозможно. Работать нужно. Упорно. - Вот и весь рецепт.

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

Третья моя заметка называлась «Главный автоматизатор». Это название кажется мне подходящим. В этой заметке я определяюсь с ролью и значением главного автоматизатора (главного конструктора АСУ). Рассматриваются некоторые типы, виды и подвиды главных автоматизаторов, встречавшихся мне в течение почти 40-летнего периода работы. С главным автоматизатором на тех фирмах, где я в последние годы работал, происходили какие-то непонятные для меня перекосы: на одной фирме в течение нескольких лет вообще не было главного; на другой фирме роль главного выполнял не главный; на третьей фирме главный автоматизатор был профаном в вопросах автоматизации. Поскольку я сам несколько лет на ЗиЛе был в роли главного автоматизатора, постольку это взгляд изнутри. Но в то же время, учитывая, что последние несколько лет я работаю программистом, это и взгляд как бы снизу и со стороны.

Четвертая заметка была написана вскоре после того, как на одной фирме, где мне довелось трудиться, внедрили систему мотивации труда программиста. Заметка называется «О мотивации». В ней рассматриваются условия эффективного функционирования так называемой системы мотивации труда программиста. Как правило, систему мотивации копируют у фирм, специализирующихся на разработках программного обеспечения. Имеет ли смысл такая система на торговых предприятиях, где программисты в численности персонала составляют едва ли больше одного-двух процентов, – первый вопрос заметки. Имеет ли смысл такая система на предприятиях кустарного типа – второй вопрос.

По-хорошему, для полноты рассмотрения проблемы следовало бы написать заметку о роли первого лица предприятия в «делах асушных». Вообще-то, этот вопрос раскрыт академиком Глушковым В.М. в его принципах разработки АСУ. Но почти во всех заметках, так или иначе, я этот вопрос затрагивал. – Он мало кому известен, а вопрос важный. Возможно, следовало бы еще изложить план перехода от кустарной формы организации, но, увы. Так получилось, что у меня ситуация, как в кинофильме «Золушка», где голос за кадром сообщает, что «ваше время истекло». Максимум, на что я оказался способен, - вычленить некоторые уже изложенные сведения по вопросу о первом лице и свести их в небольшую и довольно сумбурную заметку.

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

Без первого лица никакая реорганизация не возможна. - Последнее слово за главой фирмы. Он вот и есть главный специалист по реорганизации. Впрочем, и по АСУ тоже. Совмещать и то, и другое - удел главы фирмы, а не наемных специалистов. Совмещение на уровне "обычного" специалиста - это опять кустарщина. Требование "определение бизнес-потребностей заказчиков" к кандидату на должность системного аналитика, которое я однажды обнаружил на rabota.ru, мягко говоря, не украшает специалистов предприятия, сформулировавших его.

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

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

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

Взгляды пожилого программиста

Тем, кто жил и мыслил, а значит, и программировал ...

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

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

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

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

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

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

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

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

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

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

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

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

А вот менее очевидное положение. Программное обеспечение не любит консервации, особенно «невнедренки» в АСУ. Руководитель должен быть мудрым, чтобы предвидеть, что эффект консервации программного обеспечения – «работа на полку», фальстарт. Не стоит надеяться на то, что программное обеспечение АСУ не портится и не ломается. Это не так. - Оно старится морально и забывается. Почему-то это положение людям, далеким от программирования, кажется неверным. По-видимому, это связано с психологическим явлением: нет невыполнимой работы для человека, которому не нужно ее делать.

К вопросу о смене программистов. Программное обеспечение не любит смены программистов, когда разработку осуществлял один программист, не довел ее до внедрения, и был заменен другим программистом. Это чрезвычайная ситуация даже в условиях «западной» организации проектных работ. В условиях кустарной организации производства программ это просто катастрофа: придется начинать все сызнова. А вот смена программистов на сопровождении – естественное, вполне допустимое и чаще всего единственно возможное решение, что мне много раз довелось наблюдать на практике.

Небольшое отступление от темы. На военных кораблях второй мировой существовал так называемый ПУАЗО (пункт управления артиллерийским залповым огнем). Дело может быть организовано так, что программист, как и член команды ПУАЗО, сидит где-то в трюме ниже ватерлинии, и знать не знает, что творится наверху.

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

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

Пользователь – большой начальник (или его фаворит, - этакий трехбунчужный паша), который ожидает от программиста решения проблемы, которую сам не может сформулировать. Это, на мой взгляд, самая опасная категория пользователей. Как говорил про таких пользователей один мой знакомый, «светят отраженным светом раджи». В этой категории пользователей встречается и нагловатое барство, и производственно-бытовое вульгарное хамство. Есть еще пользователи, которых я называю близкими к делу и далекими от дела. Близкие к делу – это пользователи на операционной работе, так сказать online-производственники. А далекие от дела пользователи – это пользователи аналитических отделов или что-то в этом роде; барчуки, если по-простому. Дел фирмы они, в массе своей, всерьез не нюхали, и с этой точки зрения профессионально не подготовлены. Эти пользователи никогда не знают точно, чего они хотят, и этот тип пользователей не любят программисты.

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

И, наконец, user vulgaris – пользователь обыкновенный. Это самый распространенный пользователь, так сказать, серая масса. От него вряд ли стоит ожидать каких-либо идей в развитии АСУ. Максимум, на что он способен, - это сказать, удобно ему работать или нет. Ему следует задавать вопросы, ответы на которые могут быть только «да» или «нет». В этой категории много пользователей, для которых написание самой простой служебной записки – почти неразрешимая проблема. Именно на эту серую массу как раз и следует ориентироваться в разработках. Важно не перестараться, а то получится как в утверждении: сделайте систему для дурака, - и только дурак захочет ею пользоваться.

О печатном слове и написании инструкций, положений и прочих служебных материалов. Умение писать толковые бумаги часто недооценивается. Нелады с русским языком, - довольно серьезный изъян офисного работника. Трудно не заметить, что плохое владение русским письменным – распространенное явление и среди программистов (обычно программистов «средней руки»). Плохо, когда торжествует принцип «что получится, то и получится». Все оказывается в руках программиста-кустаря, который что слепит, тем и довольствуйтесь. Любой разработчик знает, что задание на разработку должно быть предельно ясным. Это закон. Но на практике разработчику очень редко достаются такие задания. Большая часть времени тратится именно на уяснение задания.

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

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

Наиболее распространенной организацией производства программ, особенно в период становления предприятия, является кустарная организация. Каковы особенности кустарной организации, в чем ее преимущества и недостатки. Главным признаком кустарной организации производства программ является полное отсутствие проектной документации. Заметьте, кустарный стиль определяют не методы разработки, а, прежде всего, отсутствие документации. Методы могут применяться или не применяться. – Это зависит от программистской квалификации и традиций. Не это здесь главное. Кустарная организация – это норма при рождении предприятия. Новые предприятия чаще всего стартуют, вообще не имея никакой АСУ. Автоматизацией начинают заниматься по мере роста предприятия.

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

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

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

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

Отсутствие стандартов на программирование имманентное свойство кустарной организации, ее естественное состояние. Каждый пишет, как умеет. Добиться единообразия, типовых решений не то, чтобы невозможно, такой задачи никто даже не ставит. Причем такая ситуация на всех проектных этапах разработки АСУ. Что получится, то и получится. Вся надежда на программиста «золотые мозги». Решения, которые закладывает в систему кустарь-одиночка, могут пережить своего автора, могут определить на годы вперед возможности развития системы.

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

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

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

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

Я, например, прикидывал, каков объем программного обеспечения, разработанного мной, пошел в отвал. Процентов 70 – 80. Не всегда причина в отсутствии бумаг, но свой процент эта причина забрала. А постановочный брак вообще не рассматривается, как причина. В этих процентах львиная доля - вопросы управления. А для них требуется специальное рассмотрение. Вопросы планирования и даже простого учета и контроля в условиях кустарной организации чаще всего просто не возникают. Если дело организовано кустарно, как его спланируешь. - Нет ни нормативов, ни правил, ни стандартов, ни статистики. А кто это делать будет? Да и зачем в кустарной организации это вообще нужно? Начинать совершенствовать кустарную организацию с этой стороны бессмысленно. А что означают эти самые 70 - 80%, если взглянуть на них со стороны времени. Допустим, я тружусь на нанявшую меня фирму 10 лет (что, кстати, недалеко от истины). Тогда получается, что 7 - 8 лет моей жизни фирма просто выкинула на помойку. Осознание этого энтузиазма и желания хорошо работать не прибавляет. И если работа пока еще не воспринимается, как каторга, то наплевательское отношение гарантировано. Вот что такое качество управления.

Совсем немного про бюрократию

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

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

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

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

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

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

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

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

Разработка постановки задачи - дело творческое, которое по весьма прозаическим мотивам нередко поручают дамам нерепродуктивного возраста, слабо представляющим что такое постановка задачи вообще и в АСУ в частности. И еще раз подчеркну, что почти повсеместно с документацией на постановку задачи дела обстоят плохо или даже очень плохо. Крепкая и непроходящая любовь к устному слову при изложении постановок задач - феномен, легко объяснимый. Бюрократическое правило ведь простое: старайтесь ничего не писать, дабы дурь ваша не видна была. Главное умение, которое требуется от аналитика, - это умение проектировать базы данных. Без этого умения аналитик, он вовсе и не аналитик. Но мне за последние лет 15 не встретилась ни одна аналитик-леди, владеющая этим мастерством. Это такая особенность российских аналитиков что ли? И еще: в шутку или всерьез, - как хотите, - но по моим многолетним наблюдениям худышки среди системных аналитиков женского пола - большая редкость. Такое впечатление, что главными критериями, которыми руководствуются первые лица предприятия при назначении на должность системного аналитика, являются вес и объем женщины - чем толще, тем лучше.

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

Разработать постановку задачи, составить задание на программирование - дело, почти всегда более сложное, чем разработка программы по готовому заданию. Сложность не только в том, что на этапе постановки задачи у разработчика больше степеней свободы. Программист имеет дело с компьютером, который ни уговорить, ни обмануть не удастся, а постановщик задачи имеет дело с человеком (программистом) - в этом, пожалуй, и заключается основная проблема. Велик соблазн умолчать и оставить в постановке неясный вопрос на усмотрение программиста. А имеющиеся у постановщика заблуждения программист, превратившийся в кодировщика, чаще всего не в состоянии уловить - он не знает предметной области и на 100% вынужден доверять постановщику. Проблемы неадекватной постановки задачи начнут вылезать на уровне пользователя при эксплуатации системы. Предельно ясные задания на программирование я лично получал только на вычислительном центре ЗиЛа и то только в начальный период своей работы программистом. Самая застойная, на мой взгляд, организация проектного дела - кустарно-бюрократическая.

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

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

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

О службе системных аналитиков. Создание службы системных аналитиков - огромный шаг вперед в организации разработок АСУ. Но такая служба нужна не просто так, сама по себе, служба ради службы. Когда на одном предприятии наконец-то ее создали, объем программного обеспечения, отправляемого на помойку, вырос у меня еще процентов на 10 - 15, приближаясь к 100%. Естественно, возникает вопрос о причинах такого феномена. Все дело в профессионализме лиц, набранных в службу. На более-менее серьезную фирму без минимального джентльменского набора знаний, необходимого системному аналитику, лучше не соваться. А когда руководитель службы не знает, что такое HIPO-диаграммы, не знает основных принципов разработки АСУ, никогда ничего не слышал про таблицы решений, не умеет проектировать структуру базы данных, не знает правило Де Моргана, результат для АСУ и, как следствие, для предприятия обязан быть только отрицательным. А ведь в мире изобретено и используется еще множество различных CASE-средств типа Rational Rose, BPWin, ERWin.

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

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

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

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

Кроме всего прочего, службу разработки АСУ можно организовать так, что она не будет выглядеть как единый организм. Это совсем просто: достаточно подчинить службу аналитиков одному начальнику, а программистов - другому, и в довершение разделить их территориально. Подход, много раз оправдавший себя в делах торговых, по-видимому, развил у директора силу привычки и мыслительный стереотип, который не срабатывает на делах IT-подразделения. Какого-то другого разумного объяснения тому, как службу разработки АСУ можно загнать в тупик, я пока что не нахожу. Организация разработок программного обеспечения, по моим наблюдениям, может принимать довольно причудливые формы. По-видимому, до поры до времени устройство этой службы мало волнует дирекцию предприятия. Это приводит к весьма неожиданным эффектам в работе службы. Так, на одном предприятии поведение системного аналитика один мой сослуживец квалифицировал не иначе как производственное хулиганство. Остановить системного аналитика с его нелепыми в ряде случаев требованиями было невозможно. Реализовался самодурский, солдафонский вариант. Сказать про такую ситуацию некому - дирекция фактически самоустранилась от дел, связанных с разработками АСУ. Этот, так сказать, аналитик исповедовал принцип серьезный: пусть это не вполне правильно (или даже совсем неправильно!), но главное, чтобы было по-моему - так, как Я хочу и как мне нравится. А для "прикрытия" всегда используется одна и та же отмазка: так хочет пользователь или так более удобно. Бывает, что все это совершенно без злого умысла. При попустительстве и безнаказанности ожидать более здравой организации не приходится.

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

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

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

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

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

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

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

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

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

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

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

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

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

Здесь я лишь отмечу общеизвестные факты, связанные с техническими и системными программными средствами. Из истории АСУ известно много предприятий, осуществивших перепроектированиие АСУ в связи с совершенствованием компьютеров, операционных систем, систем программирования, систем связи, технических средств ввода и вывода данных. Но вот в США и Канаде, тем не менее, существуют предприятия, до сих пор успешно эксплуатирующие системы, разработанные с применением, например, COBOL’а, который, если не ошибаюсь, был изобретен в 60-е годы прошлого столетия.

Вопрос продолжительности эксплуатации АСУ напрямую зависит от готовности предприятия к внедрению более совершенной системы. Всякая новая система должна наследовать у предшественницы только самое лучшее. Философский закон отрицания отрицания никто, кажется, еще не отменял. Новая система «со стороны», если только она по большинству параметров не превосходит свою доморощенную систему, приживается с трудом (если только она вообще приживается). Мне вот не довелось на практике наблюдать успешные внедрения систем «со стороны» взамен "своих" систем. Все предприятия, на которых мне посчастливилось когда-то трудиться и которые затевали внедрение систем «со стороны», плохо кончили. Это, например, ЗиЛ, ПромСтройБанк России, Штерн-Цемент,... Своей вины в том, что с ними случилось, не чувствую, но какая-то связь с неумелой вознёй вокруг АСУ, видимо, все же есть.

О кондициях АСУ

Посвящается памяти многих и многих АСУ, безвинно погубленных или просто профуканных

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

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

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

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

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

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

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

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

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

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

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

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

В первоначальном варианте заметки далее рассматривались конкретные недостатки прикладного функционала, созданного в условиях кустарной организации разработок. Рассматривались, например, проблемы, возникающие на уровне пользовательской дисциплины в связи с обычной бедой кустарной организации - отсутствием инструкционного материала. Рассматривались некоторые технические вопросы. Например, переход на новые версии СУБД и инструментальных систем. – Как эти вопросы решаются в «кустарных» организациях.

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

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

При некачественном решении вопроса появление нового товара (причем уже освоенного вида) каждый раз будет вызывать серьезный стресс всей системы. Многие АСУ позволяют зарегистрировать новый товар, не отслеживая всю логическую цепочку событий, связанных с его появлением. Правильное решение должно навязывать регистрацию всех необходимых данных. Из-за некомплектности данных могут не работать многие «штатные» процедуры, связанные со справочником товаров и их свойств. Ясно, что вопрос, в конце концов, будет решен. – Но как решен?! Каждый раз по-новому и какими-то варварскими методами, с безумными затратами эмоциональной и психической энергии. Вот такие решения часто и есть системные для многих предприятий, где мне "посчастливилось" поработать.

Второй вопрос на уровне постановки – это вопрос учета клиентов. Здесь мне не хочется много писать, потому что в каждой АСУ какие-то свои недочеты. Чаще всего почему-то неэффективно (и неэффектно) решается вопрос учета так называемых потенциальных клиентов.

Теперь более частные вопросы. Например, многие системы позволяют пользователям делать ошибки, исправить которые может только программист, причем сильно напрягаясь. Такая ситуация довольно типична для «кустарных» АСУ. Более того, вопрос может быть известен, и не решаться годами.

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

Незрелые IT-системы, созданные неопытными специалистами, иногда грешат наличием так называемых «открытых» процедур. Такие процедуры открыты для запуска и приводят к изменению состояния базы данных. При знакомстве с системой новичка-пользователя, как правило, предупреждают о кнопках запуска подобных процедур и возможных нежелательных последствиях при их случайном несанкционированном запуске. Только набив шишек, защищают запуск процедуры запросами. Простым аналогом таких процедур является общеизвестная команда DELETE. Вопрос защиты от ошибочных запусков, по-видимому, – это вопрос опыта и культуры проектирования.

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

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

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

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

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

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

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

Вопросы на уровне программиста. Мне встречались системы, которые с одной стороны вызывали восхищение, а с другой стороны полное уныние. И это одновременно. Кому понравится проектное решение, где на одну из основных таблиц базы данных «навешано» 38 триггеров. - Помните про 38 попугаев или ельцинских 38 снайперов?! А кому понравится хранимая процедура, сценарий которой превышает 1500 строк. – Какая уж тут проектная мудрость!

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

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

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

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

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

Конструкторы-оружейники, как известно, ревностно следят за появляющимися конструкторскими и технологическими новинками. А разработчики АСУП? Ознакомиться с лучшими образцами АСУП стало практически невозможно. Это в советское время было принято делиться опытом и ездить в командировки. В «асушных» делах чаще всего теперь задача ставится так, что лишь бы как сделать, лишь бы как работало. Проектная культура, в массе своей, как говорится, оставляет желать лучшего. И прогресса пока что не предвидится, даже, я бы сказал, наоборот, уровень подготовки специалистов падает и падает. Проектированию, как науке и искусству, у нас в ВУЗах и раньше не учили, а сейчас и подавно не учат.

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

Главный автоматизатор

Самое лучшее, что было на нашем предприятии, - это АСУ (из прощального выступления главного автоматизатора)

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

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

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

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

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

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

Цели и задачи «что делать» формулирует первое лицо предприятия. Согласно принципам разработки АСУ академика Глушкова В.М. именно первое лицо предприятия является главным руководителем. Удел главного автоматизатора – определиться с техническим заданием и проектом. Предложения «что делать», высказанные первым лицом фирмы, чаще всего, в виде лозунгов, главный автоматизатор обязан превратить в техническое задание.

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

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

АСУ несет в себе отпечаток личности первого лица, главного руководителя предприятия. - Каков поп - таков и приход (народная мудрость). Одному нравится оперетта, другому – опера …. Вспомните мультфильм, где детская считалочка «Раз, два, три, четыре, пять – вышел зайчик погулять» представляется в различных жанрах (детский утренник, оперетта, опера и др.). Задача главного автоматизатора исполнить то, что заказано и в нужном жанре. Правда, не следует понимать это буквально, и слепого бездумного повиновения быть не должно: все рождается в борьбе, муках и спорах.

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

В мелких фирмах роль главного автоматизатора, как впрочем, и системного администратора, и программиста, и постановщика задач иногда выполняет один и тот же человек. Довольно редко это лицо еще и пользователь. На средних (по численности работающих) фирмах обычно стремятся к тому, чтобы функции главного автоматизатора выполнял заместитель генерального директора - директор департамента информационных технологий. Это не всегда получается. Уровень бюрократизации главного автоматизатора обусловлен размерами предприятия. Чем крупнее предприятие, тем выше уровень бюрократизации и тем менее нагружен главный автоматизатор «настоящими асушными делами». На крупных предприятиях директор по информационным технологиям почти всегда превращается в квазиавтоматизатора. Впрочем, на крупных предприятиях действует другая схема.

Мне не доводилось работать под началом главного автоматизатора, знающего и сознательно применяющего методы проектирования в широком смысле этого слова. Методология проектирования АСУ, как правило, не самая передовая, чаще всего «приходила» откуда-то с запада. Этому в наших высших учебных заведениях почему-то не учат. Большинство из встречавшихся мне главных автоматизаторов не было знакомо даже с принципами разработки АСУ, сформулированными академиком Глушковым В.М. еще в 60-е годы прошлого столетия. А ведь эти принципы в обязательном порядке входят в классический курс лекций по АСУ.

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

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

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

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

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

Главный автоматизатор типа «новатор» хорош в начальной стадии становления АСУ или ее радикальной модернизации. В условиях налаженной системы новатор скисает, ему не интересно. Правда, это довольно редкое состояние системы, характерное во времена так называемого застоя. Значение главного автоматизатора в условиях устоявшейся системы падает. Хорошо сыгранный оркестр может обходиться и без дирижера.

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

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

Функционеры тяготеют к одному типу творчества – административному. Новатор фонтанирует идеями «по делу». В большинстве случаев он не станет размениваться на подковерно-административное творчество. - Для него это мелко. На многих дряхлеющих и загнивающих фирмах наблюдается засилье функционеров. У функционеров есть одна замечательная черта: они стараются окружить себя броневым защитным кольцом из различных заместителей. Это положение распространяется и на главного автоматизатора.

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

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

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

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

Еще «главные» подразделяются на пассивных и активных. Встречаются также главные автоматизаторы с переменной и избирательной активностью. Пассивных главных автоматизаторов, на мой взгляд, представляют «прозрачные» и созерцатели. «Прозрачные» главные автоматизаторы, они вроде как есть, а вроде их и нет. Функции «главного» они не выполняют – это вот в них главное.

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

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

Есть еще автоматизаторы, которых я называю мечтателями. Мечтатели живут «своей» жизнью. Это особый вид главных автоматизаторов, подразделяющийся к тому же на подвиды. В команде мечтателя мне работать не доводилось, а со стороны наблюдал. Наблюдал одного, похожего на Бальзаминова (из пьесы А.Н.Островского), и еще одного, ни на кого не похожего и мечтавшего, «лежа на полатях». Бывают еще фантасты. Эти генерируют какие-то нереальные проекты. Однажды у меня была встреча с представителями этого вида. - Предлагался «космический учет» автомобилей на ЗиЛе.

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

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

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

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

Экономисты и расточители составляют еще один класс автоматизаторов. Экономисты постоянно стремятся на всем экономить. Компьютеры у них устаревшие, мониторы устаревшие, системное программное обеспечение устаревшее. Расточители совершают ошибку, давно известную как ошибка избыточного оборудования: оно не нужно, но давай купим, – пусть будет.

«Черная дыра» – главный автоматизатор, обладающий страшной разрушительной силой и отрицательной энергетикой. Действует разлагающе, поглощает все и вся. Притягателен и заразен. К счастью, по большей части пребывает в спячке. Одного его присутствия иногда бывает достаточно, чтобы все пошло не так, как надо. Если он где-то рядом, - отказывают компьютеры, отказывают безотказные люди, отказывают давно испытанные программы. Упаси Бог как-то его возбудить. Решать вопросы, не попадая в поле притяжения «черной дыры», – не всем по плечу. «Такие» мне, слава Богу, никогда не попадались, но слухом земля полнится.

«Технарь» – еще один нередкий тип «главных». Этого типа автоматизаторы, даже если и не происходят от сисадмина или специалиста по ремонту средств вычислительной техники, обычно уклоняются в сторону вопросов технических. Проектные дела, задачи пользователей – в этом они в массе своей не сильны, и все это им не очень интересно. «Главные» этого типа быстро проходят путь до вульгарного учетчика и начинают напоминать табельщицу. Составить график отпусков, написать заявку на канцтовары, свести отчеты сотрудников в один общий отчет, - в общем, какие-то такие вот дела - это максимум, на что они бывают способны в части разработок АСУ.

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

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

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

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

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

Так-то вот. Тихий, ни во что не вмешивается, никому не мешает, - делай, что хочешь. Как такой «тихий» главный автоматизатор будет справляться с порученным делом – вопрос, как говорится, открытый. Когда ситуация на фирме такова, что деньги сыплются с неба, как в мультфильме про Золотую Антилопу, тогда главный автоматизатор, если и нужен, то только декоративный. – Такой, знаете ли, пупсик, чтобы глазу было приятно. Непонятно что будут делать с таким пупсиком, когда ламинарное течение сменится турбулентным. Мой опыт подсказывает, что пупсики, в конце концов, исчезают тихо и незаметно. - Ламинарность не бесконечна. Когда наблюдается тенденция к ухудшению в делах, пупсики перестают нравиться. Даже мой сослуживец с его огромной терпимостью сменил, в конце концов, милость на гнев и стал употреблять в адрес "нашего тихого" слова гораздо более презрительные и жесткие, с металлическим привкусом.

На птичьем рынке торговец продает трех попугаев.

Покупатель спрашивает про одного из них. - А что он умеет и сколько стоит?

Торговец отвечает: он умеет говорить по-русски и стоит 3000 рублей.

- А вот этот что умеет и за сколько продается? - Показывает пальцем покупатель.

- Этот еще и по-французки умеет, а стоит 5000 рублей.

- А что вы скажете про третьего попугая.

- Этот стоит 10000 рублей. - Отвечает продавец.

- А что он умеет? - Не унимается дотошный покупатель.

- А он ничего не умеет.

- Почему же тогда он такой дорогой?

- А эти двое его между собой шефом называют. - Отвечает продавец.

Этот бородатый анекдот я слышал давным-давно. Было смешно, - у меня тогда как раз начальником был "третий попугай".

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

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

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

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

«Раздражитель» – один из экзотических видов главного автоматизатора. Этот раздражает всех: пользователей, разработчиков, подчиненных, руководителей. Но вот встречается же иногда. «Прозрачный», если и не приносит пользы, то хотя бы и не раздражает. Если считать, что главная обязанность любого руководителя – сделать так, чтобы у подчиненных дела шли наилучшим образом, то нужно отметить, что таких руководителей у меня лично не было никогда. Нелишне напомнить, что главный автоматизатор – это тоже руководитель. Сплотить коллектив, воодушевить и нацелить его на решение поставленных задач – для этого «главный», прежде всего, должен быть неординарной личностью.

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

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

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

Возраст открытий, где-то я вычитал или слышал, ограничен отрезком в 20 – 30 лет. В роли успешного главного автоматизатора мне редко попадались люди этой возрастной группы. Один из самых молодых был в возрасте 27 лет и относился к типу «все замкнул на себя». Как он ни жаждал успеха, чуда не произошло. Большинство успешных главных автоматизаторов обитает в более старшей возрастной группе. По-видимому, это объясняется тем, что для успеха в «делах асушных», кроме всего прочего, необходим довольно серьезный опыт руководства людьми.

Люди пожилого возраста вполне могут справляться с обязанностями главного автоматизатора в варианте функционера. Если они и способны на какие-то открытия, - в чем я, например, сильно сомневаюсь, - то дела с энергией, необходимой на «пробивание» этих открытий, у них обстоят хуже, чем у 20-ти - 30-ти летних. А результаты «пробивания» нередко бывают лучше – такой вот парадокс. Кстати, для пожилых все довольно индивидуально: одни уже перешли на кефир и манную кашу, а другие все еще предпочитают есть мясо и гулять на сторону. Еще очень важна победная закалка в бытовых скандалах.

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

Еще раз повторюсь: все зависит от первых лиц предприятия; от того, какой они видят автоматизированную систему. Если требуется серьезная перестройка автоматизированной системы, ищите новатора. Если автоматизированная система удовлетворяет критериям первого лица и нужно только поддерживать ее плавный драйв, подойдет функционер. Поддерживать эволюцию системы в заданных рамках, обеспечивая противостояние хаосу и беспорядку, – задача непростая. Как показывает опыт некоторых кустарных АСУ, можно десятилетиями обходиться без главного автоматизатора и директора по информационным технологиям – народ сам знает, что делать! Одна из фирм, непосредственно знакомых мне по опыту работы в ней наемным программистом, безо всего без этого прекрасно обходилась, росла и процветала (до поры до времени). Это вовсе не означает, что главный автоматизатор не нужен. Он нужен, но нужен не сам по себе, как медицинский факт.

Главный автоматизатор определяет на фирме организацию и методологию проектирования и внедрения АСУ. - Если только он не пришел со стороны на все готовенькое. Имеется в виду организация в широком смысле слова, включающая весь спектр вопросов, вплоть до системы мотивации специалистов (проектировщиков, программистов, тестировщиков и др.).

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

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

Главный автоматизатор, кроме всего прочего, – политический деятель (в масштабах фирмы, конечно). Этот тезис я развивать не буду, а посоветую сравнить главного автоматизатора, скажем, с главным бухгалтером. Профессионализм встречается в любой области, если, конечно, достаточно понимаешь в деле, чтобы увидеть его. Замечу только, что успешных главных бухгалтеров все же больше, чем успешных главных автоматизаторов.

Главный автоматизатор – профессия очень непростая, имеющая свои особенности. Женщин в роли успешного главного автоматизатора я не видел ни разу. По этому вопросу мне сказать нечего. И еще я не буду здесь рассматривать обязанности главного автоматизатора, связанные с технической политикой,– какие системные средства использовать, какие СУБД и инструментальные системы закупать и т.п. В этих вопросах у меня нет достаточного опыта. А вот удержаться от упоминания нескольких вопросов «тонкой настройки», решаемых с учетом индивидуальных особенностей, не могу.

Первый такой вопрос – программировать ли «главному» самому или нет. Все зависит от конкретной ситуации и от склонностей «главного». Если коллектив программистов невелик (5 – 7 человек), то обычно «главный», если умеет, то программирует. Причем, по моим наблюдениям, программирует неплохо. Если кроме проектных дел и программирования считается, что «главный» нагружен еще вопросами обслуживания и ремонта средств вычислительной техники, он старается уйти от программирования и в результате как программист быстро деградирует. Главные автоматизаторы - фанаты от программирования не в счет. Фанаты, правда, редкость.

Да и вообще, начинающий «главный», как правило, в своем стремлении утвердиться в новой роли, считает несолидным продолжать программировать. Явление, по-видимому, социально-психологическое. Иногда это не страшно, а иногда это потеря и для дела и для программирования. Еще неизвестно, какой получится «главный», а вот программист точно будет потерян. Но, вообще-то, главный автоматизатор – самый наиглавнейший на фирме программист. Он показывает образцы высоко-художественного программирования и определяет правила и стандарты. А если он все же не умеет программировать, то это прощается ему только в одном случае - когда он блестяще проявляет себя в вопросах постановки задач, в проектных решениях, а также в управлении проектами. В последнем случае функции самого наиглавнейшего программиста должны быть кому-то делегированы. И если от программирования главный автоматизатор еще как-то может отвертеться, то от постановки задач вряд ли. Главный автоматизатор - это главный постановщик, системный аналитик номер один. Это, - как должно быть.

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

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

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

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

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

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

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

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

Наконец, доходит очередь до третьего письма. Открывает и читает последнюю инструкцию: "Пиши три письма".

О мотивации

А без денег жизнь плохая - не годится никуда!

Вопрос о мотивации труда программистов я начал было излагать в заметке о главном автоматизаторе. Но пришел к выводу, что вопрос следует рассмотреть отдельно. В заметке «Главный автоматизатор» отмечается, что главный автоматизатор определяет на фирме организацию и методологию проектирования и внедрения АСУ. Имеется в виду организация в широком смысле слова, включающая весь спектр вопросов, вплоть до системы мотивации труда специалистов (проектировщиков, программистов, тестировщиков и др.). Заметку о мотивации я также переделывал несколько раз. – Подвела первоначальная концепция. Получилось сумбурно и с повторами.

Главный автоматизатор обязан обеспечивать комплексное решение вопросов организации, не то получится, как на одной фирме, где я когда-то трудился. - Выхватили из всех вопросов только один – вопрос мотивации. Это противоречит системному подходу, а вот этого-то главный автоматизатор допускать не должен, если он, конечно, достаточно эрудирован и энергичен, и дело ему не безразлично. Но тогда попался мягкотелый функционер, готовый лечь под любого – лишь бы не напрягаться. Фирма потом канула в Лету. – Не из-за главного автоматизатора, конечно. - Кажется, там вся команда управленцев была подстать главному автоматизатору.

Система мотивации – это всего лишь один из вопросов главного автоматизатора. Система мотивации, как любая система, живет в определенных условиях. Эти условия – это в основном всё вопросы организации проектного дела и вопросы управления им. Сами знаете, в каком состоянии эти вопросы на торговых фирмах. Как вообще додумались до внедрения системы мотивации в условиях кустарной организации производства программ. Объяснение у меня только одно: непрофессионализм, помноженный на некомпетентность.

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

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

Такое вот сочетание некомпетентности на всех уровнях не могло привести ни к чему другому. Не нужно быть большим специалистом, чтобы понять, что трансформацию кустарной организации нельзя было начинать с системы мотивации. Да и кто вообще только додумался до этого, если численность программистов в численности персонала торговой фирмы редко превышает 1 – 2 процента. - Больше на фирме «мотивировать» некого было?! На самом деле это типовая ошибка некомпетентного управления. Она очень напоминает мне директорское задание на автоматизацию, выполнив которое, я вскоре после внедрения вдруг обнаружил, что подразделение «моих» пользователей расформировано. Думаю, что если бы я так программировал, как тот директор управлял, меня бы давно уволили с волчьим билетом.

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

Ну, кто сказал, что, прежде всего, для достижения полной и окончательной победы капитализма в деле разработки АСУ на фирме нужно решать именно вопрос мотивации?! Это напоминает мне решение заместителя директора по охране, которого неожиданно назначили генеральным директором. Он первым делом взял и выпустил приказ – окружить предприятие вторым рядом турникетов в проходных. Все остальные вопросы просто недоступны разуму такого директора. Может, и там тогда действовали по схожей модели?

Я не противник системы мотивации. Просто не следует телегу впереди лошади ставить. И ведь все это прописные истины. Человек слышит и видит не то, что есть на самом деле, а то, что ему хочется. - Тут вспоминается король (из сказки Шварца «Обыкновенное чудо»), который говорит придворным, что он не хочет их слушать, потому что они его только пугают («Вы не придворные, а свиньи!» - и обращается к министру-администратору за защитой).

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

Ясно, что для успешности почти любой подобной системы нужен специалист по планированию проектных работ, нужен специалист, способный дать сравнительно точную экспертную оценку полученному результату. А в условиях кустарной организации, где каждый человек на учете, такого специалиста нет. Тогда, что же получается. Опять профанация?! Система мотивации требует налаживания планирования. Планирование требует стандартов и нормативов. Выстраивается целая цепочка. В кустарной организации все это отсутствует. Переход на работу в новой системе требует подготовки. Я 8 лет проработал на заводе в отделе подготовки производства, и хорошо усвоил значение подготовки. А такая бесшабашность на частной фирме была мне в диковинку.

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

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

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

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

Я, как только представилась возможность, в свое время сразу высказал начальству свое мнение по вопросу о системе мотивации. – Работать она, как начальству мечтается, не будет. Это все было, как бы априорно. Но потом я сам лично столкнулся с действием этой системы. И окончательно утвердился в своем мнении. Дело в том, что я разработал и внедрил довольно сложную задачу, и то, как отреагировала на это система мотивации на последнем этапе, когда нужно было платить деньги, мне не понравилось.

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

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

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

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

Главный руководитель

На каждом предприятии творятся свои глупости

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

Автоматизация глупости - глупость вдвойне

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

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

Я даже сам, было, уверовал в эту сказку. Очень уж хотелось поработать под началом волшебника родом, как говорили, из Массачусетского технологического института. Вообще-то волшебники в дефиците, а в наших краях это редкость едва ли не большая, чем синяя птица. Однако откуда-то вот взялась мысль, что волшебники начнут ломиться именно на нашу фирму, в дикой конкуренции топча друг друга. – По всей видимости, опять-таки из дирекции. Это по наивности. Детская болезнь левизны в капитализме. Ну не программисты же ни с того ни с сего превратились в сказочников?! Нас и было-то всего двое.

К сожалению, сладкой сказке про Гудвина, великого и ужасного, сбыться не суждено. И не без помощи все той же дирекции на смену ожиданию всемогущего волшебника пришло ощущение, что никто уже ничего не ждет. Как будто включили счетчик на дожитие, и начался обратный отсчет минутам отпущенного времени. Тогда дирекция, чтобы не потерять реноме, взяла и назначила волшебника. После неудачи с Массачусетом его извлекли откуда-то с задворок наших палестин по чьей-то рекомендации. А он, подлец, оказался без волшебной палочки. Его так и прозвали «Ноль без палочки». И ничего – служил, пока контора не рухнула. Вообще-то, я теперь думаю, что это был самый обычный магл (даже не сквиб и уж никак не волшебник), причем довольно серый по асушному уровню. Но когда очень долго, придирчиво и скрупулезно выбирают, заканчивается это обычно так: берут под влиянием минуты кого не попадя.

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

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

Ситуация, конечно, может быть и такой: как есть, так и будет! - нас все устраивает. У других - еще хуже. Такой лозунг имеет право на жизнь. Он, конечно, не лучший, потому что не следует ожидать повышения кондиций АСУ. АСУ – материя тонкая. И если ничего не предпринимать, те минимальные достижения, которые в ней случились, - что называется «не благодаря, а вопреки», - легко могут раствориться во времени. Энтропия, знаете ли…. И накапливаются не только достижения. Ситуация меняется незаметно и быстро: сначала вместо "у других - еще хуже" возникает, что есть лучше, а потом и вообще с удивлением обнаруживают, что хуже нас уже никого нет.

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

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

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

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

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

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

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

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

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

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

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

Я придаю большое значение роли первого лица предприятия в "делах асушных". Но многим моим руководителям следовало бы прочесть книгу Карнеги "Как перестать беспокоиться и начать жить" и после этого совсем прекратить заниматься АСУ. Есть такой тип руководителей, которые как известный мультфильмовский ослик делают все наоборот. Вот аналогия с водительским мастерством. Говорят, что 5 процентов людей будут прекрасными водителями, даже если им в учителя попадется инструктор-вредитель. Другие 5 процентов людей противоположны: их не научит водить даже самый лучший в мире инструктор. Остальные 90 процентов с трудом, но научатся водить. Говорят, во всем гены виноваты. Это я все к тому, что в природе есть руководители - их тоже, по-видимому, около 5 процентов, - которые паталогически не совместимы с АСУ.

Руководителям из "этой пятерки" нужно бы перестать беспокоиться, а значит, забыть про АСУ и начать жить. Любое их участие в АСУ только наносит вред, иногда даже непоправимый. Можно же найти себе какое-нибудь "рабочее хобби". В "17 мгновеньях весны" Мюллер совершенно справедливо замечает, что у начальства нет конкретной работы. Поэтому можно, например, заняться стратегическим планированием развития предприятия или организацией питания сотрудников. Да, мало ли подобных масштабных дел при желании можно найти. Но про АСУ лучше забыть, исповедуя принцип "не навреди" и надеясь на толковых и преданных сотрудников. Признаюсь, мне в последние лет 15 почему-то попадаются руководители именно из этой "неасушной пятерки". Не думаю, что мне одному везет на руководителей, генетически не предрасположенных к "делам асушным". С нежелательно активными, в конце концов, жизнь сама разберется, а остальных ради дела придется терпеть, правда, успехов больших ожидать не стоит.

Необычайная интеллектуальная мощь, которой по умолчанию от природы будто бы наделен директор предприятия, на моей памяти ни разу не проявляла себя в IT-делах. Всякого нового своего директора я с юношеским энтузиазмом представлял себе как монстра вроде гоголевского Вия, которому достаточно только поднять веки, чтобы наступило всеобщее прозрение, а на предприятии наступила эра невиданного расцвета IT-дел. Сакраментальную фразу "поднимите мне веки" ни от одного своего босса я так и не дождался. И теперь смотрю на все более скептично и склонен больше доверять своему опыту и методу индукции: если в отношении IT-дел кишка тонка оказалась у первого, второго, ... и n-го директора, она, эта самая кишка, скорее всего будет тонка и у (n + 1)-го директора. Впрочем, у меня, кажется, уже не будет (n + 1)-го директора. Возраст, знаете ли .... Да, и вообще ....

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

Глупости типовые

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

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

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

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

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

Теперь немного про управление "делами асушными". Очевидно, что директор на самотек все пускать не должен, даже подобрав гения на должность главного автоматизатора. Чтобы создать эффективную АСУ, не так уж много существует способов. А вот чтобы натворить глупостей, способов с избытком. Защиты от дурака, как известно, не существует, – дураки ведь невероятно изобретательны. Поэтому приведу лишь несколько примеров не очень умного использования одного из самых дорогих ресурсов фирмы – разработчиков АСУ. Пример расточительного расходования программистского времени – установка и настройка программного обеспечения АСУ на компьютерах пользователей. Программист, раздающий права пользователям, следящий за изменением этих прав, - еще один пример глупого использования дорогостоящего ресурса. Я про это уже упоминал в своих "Взглядах пожилого программиста".

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

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

Когда ценой ненормального напряжения сил дело сделано, почти сразу обнаруживается, что сделано зря. Дело, казавшееся начальству, столь срочным, не только таковым не являлось, его вообще не нужно было делать. Оно не только несрочное, но главное, - оно еще и ненужное. Дело - не дело. Кроме прямого ущерба в виде напрасной траты физических, умственных и нервных сил, средств и времени, есть еще моральный ущерб. Мне лично несколько раз поручались подобные авральные дела. И ничего, - как видите выжил, несмотря на то, что никто и никогда передо мной не извинялся. Такая вот, она, культурка управления! Неэтично, но практично. Практично в том смысле, что часто практикуется. Я бы даже сказал, вошло в привычку, - привычку у одних заказывать глупости, а у других их реализовывать.

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

Еще одна типовая ситуация, которую я называю тонкой настройкой АСУ. Тонкая настройка АСУ также может быть срочным делом. Яркий пример тонкой настройки АСУ - требование к дизайну счетов на оплату, в бланк которых в предновогодний период начальство возжелало разместить рисунки елочек, снежинок, снегурочек и дедов-морозов. Когда на фирме подобным задачам уделяется чрезмерное внимание, это тревожный сигнал, особенно в условиях кустарной организации разработок АСУ. - Кондиции АСУ, по мнению того же начальства, не на высоте, и вдруг - снежинки .... У россиян есть довольно крепкое и меткое выражение: когда коту делать нечего, он яйца лижет! Оно верно отражает ситуацию. Что должен делать настоящий директор, когда АСУ застала его врасплох, и даже логин и пароль не удается вспомнить? - вопрос в стиле книги Я. Гашека о похождениях бравого содата Швейка. И, казалось бы, какая уж здесь тонкая настройка, а ничего - не получается с грубой, возьмемся за тонкую. Знай наших!

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

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

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

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

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

Очень многое в организации разработок сделано и делается с точностью «до наоборот». Результат будет, причем обязательно соответствующий. Такой же поражающий воображение, как у успешных организаций, но только со знаком минус. А как же иначе, если все вопросы решать кое-как, под влиянием момента и моментальной выгоды?! Что будет, если платить заработную плату ниже рыночной? Что будет, если службу разработки постоянно принижать?

Еще о том же. Мне не известны предприятия, которые стремятся нанять на работу неучей и неумех. Вообще-то все стараются привлечь как можно более квалифицированный персонал. Это, однако, не является 100-процентной гарантией успеха предприятия. Нужно еще умело распорядиться этим самым персоналом. Компании, в которых мне в свое время довелось трудиться, в IT-отдел набирали довольно квалифицированных программистов. Однако, результаты их деятельности нередко оставляли желать лучшего. Главной причиной такого положения почти всегда являлось неумелое руководство.

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

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

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

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

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

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

Заключение

Любое дело, даже самое простое, можно загнать в тупик.

Профукал дело - гуляй смело!

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

Процесс разработки АСУ в режиме паразитирования - явление типичное и широко распространенное во времена так называемого застоя. Результаты, как известно, были более, чем скромные. Состояние "ни жив ни мертв", как видно, возможно не только на госпредприятиях советского образца. Неконтролируемой бюрократической машине, стремящейся прежде всего к собственному благополучию, удавалось загнать в кому и более серьезные дела, чем разработка АСУ на одной отдельно взятой частной фирме, которая даже в губернском масштабе представляется величиной бесконечно малой. Дело разработки вечно, а фирмы, тем более торговые, преходящи. Что делать, когда дело разработки растоптано бездушной бюрократической машиной, я не знаю. Готового набора конкретных рекомендаций на все случаи жизни, кажется, нет. А браться за реинжиниринг или реанимацию профуканного дела - себе дороже. Холуи делать дело не умеют (у них другое предназначение), "свои" уже все сделали, что могли, а найти желающих совершить трудовой подвиг за здорово живешь среди "чужих" практически невозможно.

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

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

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

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

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

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

По поводу замены одной АСУ другой я думаю примерно вот что. Замена одной АСУ на другую без остановки предприятия – задача далеко не тривиальная. Необходимы профессионально подготовленные специалисты, досконально знающие обе системы «изнутри и снаружи». Это, так сказать, необходимое условие. А еще нужно техническое задание, технический проект, детальные планы работ и управление этими работами. Браться за такую задачу, ничего этого не имея, могут только люди, у которых легкость в мыслях необыкновенная (бальзаминовщина). И еще: чем дольше длится мероприятие, тем меньше шансов на его успешное завершение. Вообше-то, идеальный вариант – сегодня работаем со старой АСУ, а завтра уже с новой. Но для современных российских небольших торговых предприятий, на мой взгляд, этот вариант не достижим. Главное здесь, повторюсь, проблема кадров (по большей части управленческих).

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

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

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

Любая и даже самая замечательная система, как правило, внедряется с трудом. А внедрение новой управленческой системы обязательно сталкивается с человеческим фактором, с фактором сопротивления, в основе которого лежит сила привычки. Очень важно насколько система «со стороны» превосходит свою доморощенную. Человек, по природе своей, склонен к оптимальности, и нужно иметь очень сильные аргументы, чтобы заставлять его идти против своей природы и менять «шило на мыло». Но иногда вопрос все же может быть решен по-солдафонски - с помощью административного нажима. Ведь известно, что мышки плакали и кололись, но все равно продолжали жрать кактус.

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

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

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

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

Когда процесс внедрения системы со стороны длится больше года, это почти наверняка признак того, что вляпались. По-видимому, существует какой-то критический коэффициент К`, больший 0 и меньший 1 и определяющий максимально допустимый объем копирования своей системы в рамках приобретенной. Как только K > K`, так задача клонирования теряет смысл, потому что ее сложность и трудоемкость начинают превосходить возможности управленцев и разработчиков.

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

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

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

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

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

При определенных условиях проблема внедрения новой (будто бы более продвинутой) системы может перерасти из проблемы экономической в политическую. Когда предприятие не бедствует и у него образовалась приличная жировая прослойка, внедрение новой системы может происходить под лозунгом "внедрим, чего бы нам это не стоило". Это связано чаще всего с обещаниями, которые наделаны владельцам предприятия по поводу скорого и легкого внедрения, а также обещаниями, что с новой системой будем жить не тужить и "на Марсе будут яблони цвести". При таком подходе к делу затраты почти всегда будут серьёзно превосходить запланированные, а ожидание экономического чуда будет бесконечно долгим, если, конечно, предприятие выдержит.

И еще о том же: если предприятие сумело профукать свою систему управления, некогда представлявшую собой предмет особой гордости, то почему, спрашивается, это предприятие не профукает чужую систему со стороны, пусть даже лучшую из лучших? К тому же, вряд ли кто учитывает, что переход на новую систему, с остановом развития старой, в случае неудачи - довольно чувствительный удар по авторитету и реноме руководителей старшего звена, не говоря уж о директоре IT-службы. Если реноме дороже дела, то, затеяв подобное мероприятие, нужно идти, что называется, до конца. А еще можно руководствоваться принципом, изложенным Ярославом Гашеком в его бессмертном произведении про бравого солдата Швейка, где есть примерно такая рекомендация для настоящего солдата: настоящий солдат, если он провалился в клозете в выгребную яму, должен вылезти, облизаться, взять винтовку наперевес и бежать дальше как ни в чем не бывало. А у меня рекомендация лозунгового типа, как на первомайском шествии в былые времена: занимайтесь, разрабатывайте, внедряйте и совершенствуйте АСУ! Да здравствует АСУ с человеческим лицом! От АСУ, кажется, никто еще не умирал.

End of job.