Наверх

Checkin: борьба с человеческим фактором

Время чтения: 4 минуты
8
Checkin: борьба с человеческим фактором

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

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

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

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

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

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

  1. Оптимистический - подключился удаленно, установил, запустил - все работает, идет процесс допиливания.
  2. Реалистический - пришел, установил, запустил - все работает через раз, но не у всех и не так как задумывалось, пилим.
  3. Пессимистический - пришел, установил, запустил - работает, всем все равно как это работает
  4. Харизматический - пришел, что вспомнил установил/подключил/настроил. Все остальное - если вспомнит Заказчик.

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

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

  1. Качество работы команды по внедрению СЭД - важен для руководителя команды и Заказчика при приеме результатов работы;
  2. Проверку работоспособности СЭД -  позволяет избежать досадных ошибок, продиктованных человеческим фактором;
  3. Наличие всех необходимых элементов и функций СЭД, заявленных при обучении сотрудников компании - очень важен для команды по внедрению, т.к. сотрудник, прошедший обучение по учебным пособием ожидает от системы именно то, что он увидел, прочитал или изучил;
  4. Устранить ЧФ  при выполнении процедуры согласования изменений для внедрения СЭД (возврат назад по этапам, итерации).

Например, нами была разработан чек-лист для внедрения СЭД, позволяющий проверить установку, настройку и функционирование базовых и дополнительных модулей системы (базовый модуль + канцелярия).

В состав чек-лист для проверки работоспособности элементов СЭД входят следующие разделы:

1. Desktop и Web версии СЭД;

2. Работа с документами на уровне пользователя;

3. Работа с задачами и заданиями с использованием типовых маршрутов

4  и тому подобное.

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

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

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

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

Анастасия Грачева 27 сентября 2014

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

Сергей Бушмелев 29 сентября 2014

Пост хорош уже тем, что его так и хочется прокомментировать :) Думаю, автор будет не против, если услышит ряд советов со стороны:

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

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

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

Сергей, спасибо за развернутый комментарий:

1. Действительно, количество образов зашкаливает за рамки приличия. Тем не менее, реальность такова, что некоторые ситуации без образов и юмора не опишешь. За разъяснение ситуации огромное спасибо!

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

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

Альвина Мартынова 30 сентября 2014
Иногда даже стандартные функции системы по разным причинам могут не работать, это может быть и аппаратная часть и программная и недоделанные настройки. Чек лист действительно помогает протестировать Готовность системы к сдаче в опытную эксплуатацию А для прикладной разработки обычно создаются индивидуально программы испытаний, этому разработчиков и институте ещё учат; )
Иногда даже стандартные функции системы по разным причинам могут не работать

И как заказчики на это реагируют? ;)

И как заказчики на это реагируют? ;)

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

Михаил Романов 1 октября 2014
Большинство клиентов думает, что они приобретают коробочное ПО, которое запускается и работает одним нажатием кнопки мыши.

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

P.S. Ну и так - немного в сторону, но все же в контексте контроля качества вопрос: а сколько вы закладываете времени на тестирование доработок, и кто этим тестированием занимается (консультанты, разработчики, выделенные тестировщики, ...)?

Михаил Кузьмин 16 октября 2014

Полезная практика. Проверено :)

Чтобы прокомментировать, или зарегистрируйтесь