Основная сфера моей работы на протяжении 16 лет – автоматизация деятельности предприятий. Поскольку начиналось все еще в 1996 году, в небольшом городе и в отсутствии литературы по программированию персональных компьютеров – то все делалось методом проб и ошибок или «методом научного тыка». Времена поменялись, появилось множество методик (сам ими не пользуюсь) по автоматизации, внедрению и поддержке ПО для автоматизации деятельности.
Но на большинстве предприятий (сразу определимся, имеются ввиду малый и средний бизнес, бюджетные организации, крупные предприятия в состоянии развала, итого: где не могут/не хотят нанимать большие команды с современным подходом автоматизации) «умное» внедрение, просто разваливается, когда дело доходит до рядовых исполнителей. И причина ни сколько в низкой квалификации сотрудников среднего звена и исполнителей, сколько в мотивации этих сотрудников. Поэтому выработались определенные «правила», которые позволяют:
— ускорить процесс автоматизации;
— найти общий язык с руководством;
— не портить себе нервы;
Серьезные внедрения начинайте только при поддержке руководства (лиц которые имеют полномочия для принятия решений) организации. Руководству вы должны расписать, какие задачи, в каком порядке собираетесь делать. Сотрудникам донести мысль, что выполняются требования руководства, и мы их можем выполнить вместе, или это выполнят уже без нас.
Как бы ни было «выгодно» внедрение годами — не портите себе карму. Внедрять нужно быстро, чем быстрее вы решите проблему одного заказчика, тем быстрее появится второй третий. При быстром внедрении заказчик, скорее расширит задачу (и увеличит бюджет). В противном случаем можете получить минус в репутацию и минус по оплате.
Исполнители, работу которых вам поручено автоматизировать в большинстве случаев — не заинтересованы в этом, по нескольким причинам:
а) лень — «раньше было легче»;
б) нежелание переучиваться — «я только запомнил(а), что, когда, куда нажимать, зачем переучиваться?»;
в) мотивации — «мне за переобучение зарплату не поднимут. За такую ЗП хотят слишком много от меня»;
г) «я гуру» — «вы ничего не понимаете, я организовал все вот так и лучше не сделать»
а) страх за рабочее место – «сейчас внедрят и сократят»;
б) страх не научится – «мне этому не научиться»;
С группой 2 работать легче, т.к. нет внутреннего противостояния, но есть боязнь «не попасть в обойму». На таких сотрудников удобно и нужно ориентироваться. Внутренне они готовы помогать с внедрением, на них видно проблемные места, но нужно быть очень аккуратными и не «подставить» их в лице группы 1. Учтите группа 1 и группа 2 — это один коллектив «внедренцы приходят и уходят, братство коль… ектива – вечно».
Аргументы для группы 2
«а) страх за рабочее место – «сейчас внедрят и сократят»»
— руководство (инициатор внедрения) сейчас ориентировано на сотрудников, которые позволят быстро и качественно (сэкономить на внедрении) реорганизовать процессы. А мы заинтересованы, быстро и без проблем выполнить поставленную задачу. Поэтому быстрое и качественное решение задачи – выгодно для всех.
«б) страх не научится – «мне этому не научится»
— как раз все сложности новых процессов мы и должны преодолеть с вами — так, чтобы руководство об этих сложностях и не слышала.
Это группа лакмус – вашей работы, перетягиваете на свою сторону – ваша победа. Группа 1 потеряла авторитет перед группой 2 – ваша победа.
Аргументы для группы 2 должны быть технические. А организационные обсуждены под эгидой руководства.
«а) лень — «раньше было легче»»
предложенные Вами решения должны упрощать задачи и разделять их на процессы
б) нежелание переучиваться — «я только запомнил(а), что, когда, куда нажимать, зачем переучиваться»;
задача должна быть так разбита, чтобы каждый процесс можно было описать инструкцией и/или схемой, которая поместится на 1-2 листках. Лучший вариант, когда интерфейс сам является инструкцией
в) мотивации — «мне за переобучение зарплату не поднимут. За такую ЗП хотят что бы я такое умел(а)»;
с данной проблемой единственное, что помогает, спросить у исполнителя «данную проблему нам решать в режиме внедренец — руководство, или она будет решена (и не подниматься более) в режиме исполнитель — руководство». В действительности поднимать данную проблему на уровень руководства, не стоит, это усиливает конфронтацию.
г) «я гуру» — «вы ничего не понимаете, я организовал все вот так и лучше не сделать»
просить «гуру» расписать как процессы организованы на текущий момент, какие сильные и слабые стороны у действующей схемы. В 99% процесс создания схем в лучшем случае начнется.
Самое важное, что нужно понимать — руководство в первую очередь хочет автоматизировать процессы, выполняемые персоналом, который не ценится — ИСПОЛНИТЕЛЯМИ. Руководство хочет, чтобы:
— не требовалось обучения исполнителей;
— исполнители были взаимозаменяемы;
— работа исполнителей не нарушает более сложные задачи;
— схемы работы была конвейерной;
В действиях исполнителей нужно понимать:
— у исполнителя отсутствует мотивации брать на себя ответственность, поэтому все функции должны быть регламентированы;
— исполнитель не должен принимать решения, поэтому все варианты событий должны быть регламентированы;
— исполнитель, выполняя работу, думает не о ней, а о личных заботах, поэтому процессы, которые он выполняет должны быть ориентированы на простые действия: нажал, выбрал, ввел, кнопка «Ок».
И самое главное «Исполнители ВЫПОЛНЯЮТ работу, а не работают». Поэтому претензии могут быть только к правильности выполнения инструкций.
1. Решение задачи должны быть организовано в конвейер. Чем проще будет каждый этап, тем эффективней будет работать исполнитель.
2. Исполнителя нужно ставить на один рабочий (день, смену, должность) цикл, на одну функцию. Через несколько часов выполнения, он будет выполнять ее на автомате.
3. Каждый этап конвейера должен уложится в 7 операций («Магическое число семь плюс-минус два»).
4. Если этап конвейера важный, дублируйте его другим исполнителем, а в программе сравнивайте результаты. При расхождении результатов, через время (исполнителю не нужно показывать, что этап выполняется повторно), возвращайте на перевыполнение.
Ввод архивных материалов, с последующей классификацией, агрегацией и анализом.
1.1. Первичные данные хранятся на бумажных носителях, разных форм и содержания. Для ввода в систему необходимо выделить виды данных по размерам, типам, т.п. (А4, А5, ведомости, справки, выписки). Отсортировать их до ввода. При поступлении нового вида – расширить ПО.
1.2. Данные вводим сканированием в электронный архив, который будут обрабатывать на следующих этапах.
1.3. Один вид первичных данных вводит один исполнитель в один цикл.
2.1. При сканировании каждый первичный лист получает порядковый номер, который отражаем на листе, при не возможности (важные первичные данные) в реестре, который прикладывается к папке с листами, и возвращается в архив. Это даст возможность быстро найти и восстановить отсканированное в случае утери. Нумерация нужна для дальнейшей сквозной связи.
2.2. Сканирование должно уложится в 7 операций:
Новая папка
взяли папку с анкетами -> приложили реестр или указали начальный номер сканирования -> листы слева от сканера -> папка справа от сканера
Обработка листов из папки
взял лист -> в сканер -> сканировать (данные ушли в электронный архив) получили номер) -> записали номер на листе или в реестре -> положили лист в папку -> повторили
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.
Простой пример: на основе ПЦД создать (или импортировать данные в ПО анкеты физических лиц). При этом обе БД останутся независимыми, но связанными.
Агрегацию мы организовываем на новых таблицах, которые связаны с ПЦД.
Представим проблему: В архивах много дублей ФИО, Стран, Городов в Таблице Анкеты. Удалять данные из ПЦД, не стоит, т.к. при обнаружении ошибок в будущем всегда можно выяснить на каком этапе это произошло и где искать бумажный оригинал.
Рис.1. Агрегация дублей анкет
Формируем промежуточную таблицу (Т2) где будут храниться связи Анкета-Личности.
Формируем промежуточную таблицу (Т3) где будут хранится Личности и заполняем ее не дублированными записями. При нахождении дублей в (Т3) в (Т2) устанавливаем в ИД_Личности корректное значение. При необходимости можно завести описательную таблицу где указывать причины объединения в (Т2).
Рис.2. Агрегация дублей стран городов
Действуем аналогично с ФИО. Таблицы (Т2) (Т4) для Стран, (Т3) (Т5) для городов. (Т7) для связи город + страна.
— мы не нарушаем ПЦД;
— остается возможность корректировать обработанные данные;
— задача исполнителя сводится к «сверить данные, которые выглядят как дублированные».
Но на большинстве предприятий (сразу определимся, имеются ввиду малый и средний бизнес, бюджетные организации, крупные предприятия в состоянии развала, итого: где не могут/не хотят нанимать большие команды с современным подходом автоматизации) «умное» внедрение, просто разваливается, когда дело доходит до рядовых исполнителей. И причина ни сколько в низкой квалификации сотрудников среднего звена и исполнителей, сколько в мотивации этих сотрудников. Поэтому выработались определенные «правила», которые позволяют:
— ускорить процесс автоматизации;
— найти общий язык с руководством;
— не портить себе нервы;
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.
Простой пример: на основе ПЦД создать (или импортировать данные в ПО анкеты физических лиц). При этом обе БД останутся независимыми, но связанными.
Агрегация
Агрегацию мы организовываем на новых таблицах, которые связаны с ПЦД.
Представим проблему: В архивах много дублей ФИО, Стран, Городов в Таблице Анкеты. Удалять данные из ПЦД, не стоит, т.к. при обнаружении ошибок в будущем всегда можно выяснить на каком этапе это произошло и где искать бумажный оригинал.
Рис.1. Агрегация дублей анкет
Формируем промежуточную таблицу (Т2) где будут храниться связи Анкета-Личности.
Формируем промежуточную таблицу (Т3) где будут хранится Личности и заполняем ее не дублированными записями. При нахождении дублей в (Т3) в (Т2) устанавливаем в ИД_Личности корректное значение. При необходимости можно завести описательную таблицу где указывать причины объединения в (Т2).
Рис.2. Агрегация дублей стран городов
Действуем аналогично с ФИО. Таблицы (Т2) (Т4) для Стран, (Т3) (Т5) для городов. (Т7) для связи город + страна.
Результат:
— мы не нарушаем ПЦД;
— остается возможность корректировать обработанные данные;
— задача исполнителя сводится к «сверить данные, которые выглядят как дублированные».
