Текст книги "Те же 10 вопросов через 20 лет. Офис и компьютер"

Кому помочь – сотруднику или предприятию?

 
Было в конторе узкое место.
Было сотруднику в нем очень тесно.
Было расширено узкое место.
Стало сотрудникам всем очень тесно.
 

Что за вопрос?! Конечно, и сотруднику, и предприятию!

Прекрасно, но как этого добиться? И в чем, собственно говоря, «помочь»?

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

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

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

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

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

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

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

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

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

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

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

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

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

К сожалению, это не всегда так, о чем говорит наш опыт, полученный при продвижении системы ЛокОФФИС на рынок.

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

Уже на этом этапе мы получаем информацию о том, кто на предприятии заинтересован в системе.

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

а) если звонил программист, а руководство не заинтересовано в инвестициях в автоматизацию, то второго звонка можно не ждать;

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

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

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

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

И только когда интерес к системе проявляет первое лицо – кому за это «платят» – мы демонстрируем систему тому, для кого она предназначена.

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

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

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

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

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

О том, как соединить эти две системы, пойдет речь в следующей главе.

Одна из неизбежных проблем, встающих перед предприятием при переходе на автоматизированные средства управления, – это внедрение.

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

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

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

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

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

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

В случае внедрения автоматизированной системы проблема изменяется качественно.

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

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

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

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

По мере освоения простых операций станут видны способы исполнения более сложных на базе средств автоматизации.

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

Соблазн создать замкнутую автоматическую систему должен сдерживаться соображениями внедрения: ведь такую систему можно внедрить только целиком.

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

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

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

Какова степень инструментальности предлагаемой системы?

Сразу отмечу, что о противопоставлении систем здесь речь не пойдет. Более того, все рассуждения здесь проводятся ad hoc[16]16
   Для данного случая (лат.). – Прим. ред.


[Закрыть], поэтому сначала определим, что будем понимать под указанными в названии системами.

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

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

Интересен вопрос: что заставляет разработчиков заложить в программу тот или иной набор настраиваемых параметров?

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

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

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

Наиболее ярко это проявляется в популярных рыночных продуктах. Разработчики Windows включили в свой продукт все известные им драйверы указателей, принтеров, мониторов и т. п., и кроме того дали возможность присоединить иные, им неизвестные. Разработчики бухгалтерского пакета “Scala”, который используется в 55 странах, предоставляют пользователям возможность настроить его на любую методику ведения учета в любой из 18 валют, на любом из 33 языков. Как только разработчики узнают об отсутствии в их программе необходимой настройки, они стараются ее включить.

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

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

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

Существуют объективные факторы, влияющие на применяемость средств автоматизации и зависящие от степени их инструментальности.

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

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

Вопрос в немалой степени провокационный. Ответ, казалось бы, очевиден, но на самом деле не так прост.

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

Прежде чем обсуждать средства разработки, следует определить ее цель:

надо создать – заказную уникальную систему или программный продукт для рынка?

это будет прикладная программа или инструментальная система?

какой предполагается срок жизни программы?

придется ли ее сопровождать (т. е. вносить изменения в нее по желанию заказчика) или только исправлять ошибки?

Есть еще много вопросов, ответ на которые в какой-то мере влияет на выбор средств.

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

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

Многие в то время прогнозировали – и не ошиблись, что большинству бирж отпущено 1,5 – 2 года. Приблизительно столько занимает разработка серьезной системы. Кто бы ей пользовался сегодня?

Сейчас похожая ситуация с банками.

Завтра та же участь ждет инвестиционные фонды.

Послезавтра настанет черед страховым обществам.

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

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

Если фирма берет на себя обязательства перед покупателем, она не может позволить появиться на рынке ненадежному или слишком медленному, или неудобному в использовании продукту.

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

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

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

На протяжении всей статьи я задавал вопросы.

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

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

А можно ли вообще найти окончательные ответы на поставленные вопросы? Есть ли предел в развитии средств автоматизации?

Да и что такое автоматизация? Техническая дисциплина, прикладная наука, продукт ремесленного труда?

В зависимости от угла зрения можно ответить утвердительно на все вопросы. Но известно, что множество верных ответов говорит о неправильно поставленном вопросе.

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

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

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

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

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

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

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

Автоматизация идет следом за познанием, но никогда не предшествует ему.

Процесс познания начинается с вопросов.

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

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

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

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

Выход у работника только один: знать, думать и отвечать надо самому, а компьютер – это только помощник, и не больше!

Сначала знать – потом делать! Другого пути нет.

Точно так же – сначала поставить вопрос, потом найти ответ.

Иначе не получится!

По этой причине я и задавал вопросы, чтобы искать на них ответы.

По этой дороге познания идет много людей. В том числе и наша фирма ЛокИС.