Человеческий фактор в работе информационных систем

30.05.17

Управление проектом

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

Пользователи – источник бардака в системе

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

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

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

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

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

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

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

Какие цели у вендора, когда он выводит систему на рынок? Ему нужно ее продать – он придает ей функциональность и гибкость. Функциональность – это количество фич, которые реализует данная система, то есть набор ее возможностей. Гибкость – это возможность использовать все эти фичи в любом порядке и десятью разными способами. То есть задача вендора – чтобы его система подошла максимально возможному количеству потенциальных покупателей. Но когда эту систему покупает одна конкретная контора, одно какое-то конкретное предприятие, какие бы у него ни были извращения, это лично его извращения. Потенциальные извращения остальных потенциальных покупателей его не волнуют: он хочет так, как у него. Но, как мы понимаем, от того, что он хочет, и от того, что он ее купил, ни функционал, ни гибкость системы никуда не исчезли. Только теперь что это значит? Это значит, что из 100% функционала ему нужна первая, пятая, пятнадцатая и двадцать пятая фича. Остальные ему в принципе не нужны. И не просто не нужны – их использование вредно, потому что они могут делать что-то альтернативными способами, а ему нужно только так.

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

Поэтому первое, о чем вы должны задуматься, когда вы находитесь на этапе внедрения системы, – о людях. Представьте, вы продали систему, которая покрывает 80% ваших требований. Клиента обучают, как пользоваться теми 80%, которые есть, и доделывают недостающие 20%. Но при этом те, кто в ней работает на этих 80%, начинают упираться. И у вас возникает проблема – дети, играющие со спичками, и результатом этой проблемы становится пожар. Когда пожар уже возник, вы в принципе понимаете, что его причина в детях, играющих со спичками, но когда пожар – уже не до детей. Надо тушить! Бегом, срочно, сейчас! Делать костыли!

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

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

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

 

Этапы внедрения системы и проблемы на каждом из них

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Как контролировать действия пользователей

Самое главное: что же со всем этим делать?

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

Здесь речь идет о том, как пользователь будет заполнять карточку, удобства для него, какие-то там обработки занесения и загрузки из Excel, формирования на основании предыдущих документов и т.д. и т.п. Все это, конечно, хорошо, но это благотворительность, это все надо оставить на потом.

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

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

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

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

И напоследок небольшие рекомендации.

 

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2734    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

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

05.07.2023    14236    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5820    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4655    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

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

27.12.2022    2733    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4153    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

09.09.2022    10594    0    biimmap    79    

73

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13030    0    Evil Beaver    17    

116
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. kuzyara 1896 31.05.17 10:28 Сейчас в теме
Чувствуется у автора, что называется, накипело.

Интересно, есть ли инструменты для timelaps'а входящего потока данных?
2. aspirator23 339 31.05.17 11:48 Сейчас в теме
Полезная статья. Позволяет посетителям конференции сходить пообедать, позвонить на работу, поучаствовать в обсуждениях в малом зале. Это как в школе. 1 урок математика, 2 - русский язык, 3 - Оба-на! физкультура. А далее 4 - иностранный язык, 5 - биология
корум; Tefal; a_a_burlakov; +3 Ответить
3. citicat 119 31.05.17 15:12 Сейчас в теме
Для работы системы нужна к ней инструкция. Желательно, под подпись : " Я , Иванова Т.С., кладовщик, ознакомилась с инструкцией по экслуатацией ****".
4. denker 31.05.17 15:14 Сейчас в теме
(3) Не поможет, если система позволяет Татьяне Сергеевне вводить те данные, которые она не должна.
Ну накажете гражданку Иванову, она обидится-уволится, думаете другая гражданка будет лучше?
6. citicat 119 01.06.17 18:43 Сейчас в теме
(4)Придётся писать отдельную статью по системам учёта и их внедрению. Поставлю в свой план.
7. Peltzer 05.06.17 11:13 Сейчас в теме
(3) Очень редкий человек/пользователь читает инструкцию. Программный продукт должен быть понятен без инструкции в идеале.
5. IvanovAV 131 31.05.17 16:52 Сейчас в теме
Статью не осилил, много буков, но за классные картинки поставил +
Оставьте свое сообщение