Автоматизация ИТ процессов в условиях низкой мотивации и/или квалификации исполнителей

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

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

— ускорить процесс автоматизации;
— найти общий язык с руководством;
— не портить себе нервы;

1. Уровень внедрения


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

2. Сроки внедрения


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

3. Не обижайтесь на «саботажников»


Исполнители, работу которых вам поручено автоматизировать в большинстве случаев — не заинтересованы в этом, по нескольким причинам:

Группа 1. не хотят менять привычный режим работы т.к.:

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

Группа 2. боятся менять привычный режим работы т.к.:

а) страх за рабочее место – «сейчас внедрят и сократят»;
б) страх не научится – «мне этому не научиться»;

Рассмотрим подробнее.


Группа 2

С группой 2 работать легче, т.к. нет внутреннего противостояния, но есть боязнь «не попасть в обойму». На таких сотрудников удобно и нужно ориентироваться. Внутренне они готовы помогать с внедрением, на них видно проблемные места, но нужно быть очень аккуратными и не «подставить» их в лице группы 1. Учтите группа 1 и группа 2 — это один коллектив «внедренцы приходят и уходят, братство коль… ектива – вечно».

Аргументы для группы 2

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

Группа 1

Это группа лакмус – вашей работы, перетягиваете на свою сторону – ваша победа. Группа 1 потеряла авторитет перед группой 2 – ваша победа.

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

«а) лень — «раньше было легче»»
предложенные Вами решения должны упрощать задачи и разделять их на процессы
б) нежелание переучиваться — «я только запомнил(а), что, когда, куда нажимать, зачем переучиваться»;
задача должна быть так разбита, чтобы каждый процесс можно было описать инструкцией и/или схемой, которая поместится на 1-2 листках. Лучший вариант, когда интерфейс сам является инструкцией
в) мотивации — «мне за переобучение зарплату не поднимут. За такую ЗП хотят что бы я такое умел(а)»;
с данной проблемой единственное, что помогает, спросить у исполнителя «данную проблему нам решать в режиме внедренец — руководство, или она будет решена (и не подниматься более) в режиме исполнитель — руководство». В действительности поднимать данную проблему на уровень руководства, не стоит, это усиливает конфронтацию.
г) «я гуру» — «вы ничего не понимаете, я организовал все вот так и лучше не сделать»
просить «гуру» расписать как процессы организованы на текущий момент, какие сильные и слабые стороны у действующей схемы. В 99% процесс создания схем в лучшем случае начнется.

4. Немного об исполнителях или грубо о правде.


Самое важное, что нужно понимать — руководство в первую очередь хочет автоматизировать процессы, выполняемые персоналом, который не ценится — ИСПОЛНИТЕЛЯМИ. Руководство хочет, чтобы:

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

И самое главное «Исполнители ВЫПОЛНЯЮТ работу, а не работают». Поэтому претензии могут быть только к правильности выполнения инструкций.

5. Требования к ПО


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

6. Пример задачи



Ввод архивных материалов, с последующей классификацией, агрегацией и анализом.

1. Подготовка.

1.1. Первичные данные хранятся на бумажных носителях, разных форм и содержания. Для ввода в систему необходимо выделить виды данных по размерам, типам, т.п. (А4, А5, ведомости, справки, выписки). Отсортировать их до ввода. При поступлении нового вида – расширить ПО.
1.2. Данные вводим сканированием в электронный архив, который будут обрабатывать на следующих этапах.
1.3. Один вид первичных данных вводит один исполнитель в один цикл.

2. Сканирование

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

2.2. Сканирование должно уложится в 7 операций:
Новая папка
взяли папку с анкетами -> приложили реестр или указали начальный номер сканирования -> листы слева от сканера -> папка справа от сканера
Обработка листов из папки
взял лист -> в сканер -> сканировать (данные ушли в электронный архив) получили номер) -> записали номер на листе или в реестре -> положили лист в папку -> повторили

3. Распознавание отсканированных данных

3.1. Структуру БД описывать не буду, тут по-моему все ясно.
3.2. Каждый исполнитель в пределах цикла распознает один вид документа.
3.3. Если данные списочные, каждая строка (2-3 строки) выделяется в анкету и исполнитель работает с анкетой. Например
3.3.1. Анкета представляет таблицу: Показатель, Значение. (Показатели: ФИО, Дата рождения, Пол, Страна, Город)
3.3.2. Ведомость представляет собой таблицу: №, ФИО, Дата рождения, Пол, Должность, Страна, Город … Значит, анкетой считается каждая строка.
3.4. Пользователю для распознавания выделить строку (для ведомости), показатель и значение.
3.4.1. Для анкеты, например, при фокусировке на поле ввода ФИО, выделять показатель и значение.
3.4.2. Для ведомости выделять, строку, показатель и значение.
3.5. На указанных примерах мы имеем блоки
Показатели: ФИО, Дата рождения, Пол, Должность.
В ведомости еще группировки по строкам.
3.6. Количество полей для ввода за один цикл, желательно, ограничивать. Например, исполнитель вводит из анкеты только ФИО и пол. Это быстрее доведет работу до автоматизма.
3.7. Один и тот же блок вводят два и более исполнителя (дублируют). На основе сверки расхождения отправляем на повторный ввод. Это избавит нас от проверки вручную.

На этот момент мы имеем:

1. Налаженный процесс преобразования бумажных данных в цифровое представление –первичные цифровые данные «ПЦД».
2. Отсканированный архив (частично или весь)
3. Распознанные данные (частично или весь)

Классификация

Теперь можно на базе ПЦД, организовать БД2 в которой классифицировать данные по типам первичных данных и блоков, при этом не нарушая ПЦД. Например все ведомости в БД2 будут в 1 таблице т.к. это по сути анкеты и наоборот все анкеты свести в ведомости. При этом преобразования в случае ошибок или смены правил можно переимпортировать. На этом этапе главное разработать правила преобразования ПЦД в БД2.
Простой пример: на основе ПЦД создать (или импортировать данные в ПО анкеты физических лиц). При этом обе БД останутся независимыми, но связанными.

Агрегация

Агрегацию мы организовываем на новых таблицах, которые связаны с ПЦД.
Представим проблему: В архивах много дублей ФИО, Стран, Городов в Таблице Анкеты. Удалять данные из ПЦД, не стоит, т.к. при обнаружении ошибок в будущем всегда можно выяснить на каком этапе это произошло и где искать бумажный оригинал.

image
Рис.1. Агрегация дублей анкет

Формируем промежуточную таблицу (Т2) где будут храниться связи Анкета-Личности.
Формируем промежуточную таблицу (Т3) где будут хранится Личности и заполняем ее не дублированными записями. При нахождении дублей в (Т3) в (Т2) устанавливаем в ИД_Личности корректное значение. При необходимости можно завести описательную таблицу где указывать причины объединения в (Т2).

image
Рис.2. Агрегация дублей стран городов

Действуем аналогично с ФИО. Таблицы (Т2) (Т4) для Стран, (Т3) (Т5) для городов. (Т7) для связи город + страна.

Результат:

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

Комментарии 19

    +8
    честно написано
      +3
      В моём админском опыте был сформировалось очень простое правило: приживаются только те решения, которые людям дают улучшение их работы, или не влияют на expirience. Условно говоря, выпиливание freebsd и замена на linux никого не волновала (потому была успешной). Внедрение терминального сервера вызывало нарекания, пока люди не обнаружили, что на ТС быстрее и можно подключаться из дома.

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

          Но преодоление сопротивления — это деньги. Те, кто говорит «а, всё равно заставим» и не предусматривает этого в бюджете — натыкается на итальянские забастовки, луддизм, отток персонала, снижение эффективности труда и ухудшение атмосферы в коллективе.

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

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

            От этого много проблем. Работать-то на внедрении и потом будут именно рядовые работники, но их заинтересованности им иногда проще уволиться и перейти на такую же работу в другом месте.
              0
              Не всегда. Когда внедряется новое средство, и оно позволяет упростить существующую деятельность, то обычно оно взлетает на «ура». Я помню, как взлетало видеонаблюдение за охраной для начальника охраны из дома (сторож для сторожей). Главой проблемой было наше (ИТ-отдела) сопротивление. С точки зрения исполнителей всё было просто очень гладко, потому что ей это заменяло отзвонку на пост охраны и утренее (пост-фактум) разглядывание кино.
                0
                всегда. Под внедрением я имею ввиду что-то крупное, типа перехода с 1C на SAP R3, т.е. то что требует не просто установки новой камеры с новым проводом а работы бухгалтеров по субботам, сверхурочных часов менеджерам для обучения, дублирования документов в обоих системах на период внедрения и пр.
                  0
                  О, так я про это примерно и говорю: если есть херня для исполнителей (дополнительная работа, телодвижения, ограничения, более сложный процесс), то если этот процесс ИМ конкретно (а не компании) не даёт улучшений — нужно закладывать это в бюджет.

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

                  Альтернатива — «кто не перейдёт — будет уволен». Дисциплинирует (если действительно уволняют), но часть может сказать «так я и сам, того, спасибо».

                  И вся драма внедрений состоит в том, что этот бюджет часто не учитывают. Учитывают какие-то громады, но не учитывают существование в 1С кнопочки (утрирую) F13, которая выводит список текущих конагентов, по которым были операции за день. В SAP это будет меню, пункт, вкладка, задать параметры «с» и «до» (а по-умолчанияю там с 1970 по начало месяца, потому что так было удобно генеральному), поставить галочку «для одного сотрудника», выбрать в словаре себя и нажать «генерировать отчёт» (который делается 110с).

                  Ну и какая реакция на это будет человека?
        +2
        Вы забыли исполнителей, которые не хотят автоматизации, т.к. сейчас они халтурят 90% времени и никто не замечает, а после оптимизации придется работать =))))
          +1
          Я бы отнес их группе 1. Но есть еще один аспект. Если нагрузить исполнителя работой (под работой я понимаю, что исполнитель думает только о работе) даже на 20% — он сбежит. В оптимизации важно чтобы выполнение какой-то задачи не загружало исполнителя на 100% способностей. Например была такая компания. Рабочий день 9-18. Но вся нагрузка происходит с 16 до 18, остальное время офис бродит. Получается что работают только 20% времени. Если загрузить работой эти 20% полностью — сбежит. Поэтому на эти 20% времени у него был регламентированный список действий.
          Я бы сказал, в оптимизации главное разделить: с одной стороны процессы, а к ним можно подставлять исполнителей.
          +1
          всё правильно написал. молодец, теперь можно будет просто давать ссылку.
            +5
            Очень правильно, да. Я бы ещё в процесс внедрения включил психологические аспекты, нечто вроде дрессировки: того поругать, а вот того похвалить.

            Самая главная проблема практически всех таких процессов внедрения в том, что они ориентированы на начальство: чтобы начальнику рисовался красивый график, чтобы на его айпаде можно было тыкать и смотреть статусы и так далее. А собственно о потребностях исполнителей мало заботы. В итоге получаются убогие и ужасные интерфейсы, криво написанная документация и так далее.
              +2
              Согласен. Навыки управленца и психолога в процессе внедрения очень важны.
              Ну и обязательно надо навести порядок в бизнес-процессах компании, которых будет касаться автоматизация.
              Как говорит автор книги Записки автоматизатора. Профессиональная исповедь: «Результатом автоматизации бардака всегда будет автоматизированный бардак»
                0
                «Автоматизировать хаос нельзя!», но порой это единственный путь. Откусывать хаос, структурировать и выкладывать процесс уже через ИС. И так кусок за куском, кусок за присест, и слон будет съеден.
                +1
                Как я мотивирую на работе двух сотрудниц обучаться полезным фишкам в новых версиях AutoCAD: «Вот такие и такие инструменты сокращают время работы над чертежами на 30%, благодаря этому можно быстро начертить и отдыхать пока следующее задание появится.»
                  0
                  Спасибо, отличный материал. Прям сейчас кое-кому отправлю ссылку, у нас как раз активно ведется внедрение и есть некоторые трудности с группой 1 у заказчика.
                    0
                    не столько ..., сколько…
                      0
                      Хочется сделать ещё одну ремарку.

                      Очень важно среди рядовых работников иметь поддержку внедрения. Если довести работника до понимания того, что ваша система упростит ему жизнь, заинтересовать его, то будет:
                      а) Свой человек, который сможет дать быстрый фидбек до окончания внедрения (а ему дальше с этим работать, он заинтересован в улучшении и «допилке» системы). Это позволит сильно снизить сопротивление внедрению, т. к. конечные пользователи будут видеть, что работа ведется не ради красивых графиков руководства, но и ради повышения их производительности. А увеличение вовлечения пользователей очень полезно.
                      б) «Первая линия» техподдержки средствами заказчика. Пользователям зачастую проще спросить своего коллегу, чем использовать формальную процедуру взаимодействия с техподдержкой или разбираться с документацией.
                        +1
                        в госучереждениях, да и наверно в некоторых учреждениях есть еще 1 случай — когда коммерсы впаривают свое калечное решение (не без откатов конечно, на уровне руководства), причем настолько нагло и открыто что диву даешься, при том что обслуживать все это будут те же 2 с половиной человека, и ответственность за работу после внедрения этого горепродукта лежит именно на них.

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