Пользователи – источник бардака в системе
Представьте, у нас есть некая система. Не важно - типовая, нетиповая, созданная. Смысл существования любой системы в том, чтобы в ней работали люди. Люди ее оживляют. Но в то же самое время эти люди являются основным источником проблем в этой системе, то есть они ее разрушают, вносят в нее бардак, потому что работают в ней не так, как система это предусматривала. Причем совсем не обязательно, что они делают это намеренно. Нет, просто люди чего-то не знают, что-то не понимают, кто-то недостаточно опытен, кто-то недостаточно образован или просто внимателен. То есть, работает большая-пребольшая группа людей, которая не согласована, в результате чего общая картина может рушиться.
Один из основных источников данной проблемы – так называемое «очеловечивание» компьютера в представлении людей. Представьте, есть компьютерный мир, мы можем обозвать его виртуальным (т.е. наша система) и есть реальный мир. В чём их отличие?
Предположим, нет у нас никакого компьютера. У нас работает некая контора «Купи-продай». Она что-то привозит, ставит на склад на полочки, приезжает клиент, ему это с полочки снимают, загружают в машину, он уезжает. Хозяин этой конторы для того, чтобы узнать, скажем, свои остатки, звонит кладовщику и просит посмотреть, сколько белых кружечек осталось. Кладовщик подходит к полке, смотрит на нее, считает… 5 коробок. То, что мы привезли, и то, что мы отдали клиенту, мы можем документировать, то есть мы сначала привезли, поставили на полку, потом оформили какие-то документы. У нас что-то произошло в реальной жизни, потом мы это как-то задокументировали. Причем, есть одно свойство, если мы поставили на полку коробку с белыми кружками, как бы мы это ни документировали, в реальности это будет одна коробка с белыми кружками. Даже если мы ошибемся в документе или вообще забудем его выписать, не отдадим его клиенту, он его не подпишет – неважно, в реальности это будет одна коробка с белыми кружками. Если приехал клиент, мы ему отдали одну коробку с синими кружками, что бы мы ни написали в документах, какую коробку мы забрали с полочки, та коробка и исчезла. Что мы положили клиенту в машину, то у него в машине и появилось. И нет нужды это контролировать, это контролирует Господь Бог. Так наш мир устроен. По-другому быть не может.
Компьютерный мир устроен прямо противоположно. То есть, мы туда сначала что-то вносим, какие-то документы документируем, и на основании этих документов система генерит нам реальность. Но люди об этом обычно не задумываются. То есть начальник, который завел себе эту систему, уже не звонит кладовщику и не бежит сам считать, что у него осталось. Он пользуется системой и в принципе полагает, что все осталось как было раньше Только раньше он кладовщику звонил, а теперь он может просто открыть систему и увидеть тоже самое. То есть человек не задумывается о том, что может быть по-другому. В жизни у него было так, теперь это будет также в компьютере.
Но в действительности мы понимаем, что компьютерная реальность зависит от того, как мы внесли в систему документы. И если мы внесли их неправильно, ошиблись, выбрали не те кружки или не тот склад, не ту полку, не того клиента, или вообще не провели документ, или сделали позже, чем начальник посмотрел, – картина мира от этого будет меняться. Если мы залезли задним числом – меняется картина, выбрали не ту полочку – меняется картина. Но до людей это не доходит, люди об этом не думают.
На самом деле, только когда пользователи ударяются об эти проблемы, они осознают, что, оказывается, в компьютерном мире, для того, чтобы cгенерированная им картина была адекватна реальности, надо соблюдать какие-то правила, которые соблюдать в реальной жизни не было нужды. В реальном мире независимо ни от чего картина гарантированно правильная. В компьютерном – все совсем иначе. И людей это повергает в шок, когда они с этим сталкиваются.
Следующая вещь, которая приводит к таким проблемам. Существование информационной системы можно поделить на два этапа: первый – когда систему создает вендор и выводит ее на рынок и второй – когда ее покупает один конкретный пользователь, одна конкретная контора, которая теперь собирается использовать ее для своих целей.
Какие цели у вендора, когда он выводит систему на рынок? Ему нужно ее продать – он придает ей функциональность и гибкость. Функциональность – это количество фич, которые реализует данная система, то есть набор ее возможностей. Гибкость – это возможность использовать все эти фичи в любом порядке и десятью разными способами. То есть задача вендора – чтобы его система подошла максимально возможному количеству потенциальных покупателей. Но когда эту систему покупает одна конкретная контора, одно какое-то конкретное предприятие, какие бы у него ни были извращения, это лично его извращения. Потенциальные извращения остальных потенциальных покупателей его не волнуют: он хочет так, как у него. Но, как мы понимаем, от того, что он хочет, и от того, что он ее купил, ни функционал, ни гибкость системы никуда не исчезли. Только теперь что это значит? Это значит, что из 100% функционала ему нужна первая, пятая, пятнадцатая и двадцать пятая фича. Остальные ему в принципе не нужны. И не просто не нужны – их использование вредно, потому что они могут делать что-то альтернативными способами, а ему нужно только так.
Что касается гибкости, которая существовала в системе, когда ее предприятие купило, она тоже никуда не исчезла, она просто опустилась уровнем ниже – на сотрудников этого предприятия. То есть теперь сотрудники предприятия могут делать одни и те же вещи десятью разными способами в зависимости от настроения, дня недели, проведенного вчера вечера и т.д. И это уже совсем нехорошо. То есть то, что было преимуществом на первом этапе, на втором этапе таковым не является, и даже является проблемой.
Поэтому первое, о чем вы должны задуматься, когда вы находитесь на этапе внедрения системы, – о людях. Представьте, вы продали систему, которая покрывает 80% ваших требований. Клиента обучают, как пользоваться теми 80%, которые есть, и доделывают недостающие 20%. Но при этом те, кто в ней работает на этих 80%, начинают упираться. И у вас возникает проблема – дети, играющие со спичками, и результатом этой проблемы становится пожар. Когда пожар уже возник, вы в принципе понимаете, что его причина в детях, играющих со спичками, но когда пожар – уже не до детей. Надо тушить! Бегом, срочно, сейчас! Делать костыли!
Пока тушили один пожар, возникло еще три. Пока тушили эти три, возникло еще шесть. И это превращается в беготню по кругу, когда вы до систематизации того, что в систему попадает, не дойдете никогда. Дети у вас останутся. Вы всегда будете тушить пожары.
Это происходит очень часто и приводит к тому, что ваша кастомизированная система превращается в набор костылей. То есть эти 20% представляют из себя огромное количество костылей.
Получается вот такой замечательный набор, как на картинке. Вроде все стоит на одной полке, но все разного цвета, разного размера, разного вкуса.
Этапы внедрения системы и проблемы на каждом из них
Если процесс внедрения системы в организации разделить на три этапа, то этап первый – покупка и попытка посадить всех людей в работу в едином поле. Если раньше в компании были разрозненные люди, каждый из которых варился в собственном соку, то поставленная и внедренная информационная система означает, что теперь все должны работать в едином поле и общаться не через «человек-человек» коммуникацию, а в варианте "человек-компьютер-человек".
Это порождает ряд проблем, одна из которых – очеловечивание компьютера. Некоторые думают, что то, что они делали раньше без компьютера, они теперь просто будут делать с компьютером, и в принципе получатся те же результаты, только не надо будет бегать, звонить, они просто это в компьютере откроют и посмотрят. Люди не подозревают, что существует ряд законов и правил, которые в компьютерном мире надо соблюдать, потому что в жизни у них не было таких проблем. Они с этим не сталкивались.
И цель первого этапа довести всю работу до того уровня, который уже был, когда мы работали без системы, то есть дойти до точки "0". Вернуться обратно, чтобы теперь с помощью системы иметь то, что у нас и так уже было. Вот это первый этап. Многие не готовы к тому, что когда мы внедряем какую-то систему автоматизации, сначала нам гарантировано становится хуже! Людей это повергает в шок и ужас. Зачем вообще все это затевалось, если стало хуже?!
Второй этап – когда мы делаем то же самое что и раньше, но теперь все это у нас в компьютере, в одной замечательной системе. И мы теперь хотим поиметь от системы то, ради чего все дело затеивалось, ради чего тратились деньги. Начинается добавление в нее чего-то нового, каких-то возможностей, которых раньше не было просто потому, что без компьютера они немыслимы.
Здесь возникают свои проблемы, потому что люди опять-таки мыслят человеческими категориями. Проектирование новых возможностей системы делается людьми в варианте "для людей". Снова все внимание уделяется возможностям, т.е. - тому что должно быть в системе, и почти не уделяется тому, чего быть не должно.
И третий уровень – самый крутой. В реальной жизни он встречается крайне редко. Это когда некую бизнес-логику, выстроенную в системе, пытаются масштабировать, то есть открывать филиалы и ставить туда тоже самое, сделать франшизу и т.п. На этом этапе тоже возникают свои проблемы, потому что люди с удивлением обнаруживают, что в системе все-таки работают люди. И очень многое зависит от них. И если просто повторить такое предприятие в соседнем городе, оно почему-то не так работает. И это тоже вызывает у людей удивление, хотя вроде бы ничего сложного в этом нет.
Вот одно из заблуждений, которое появляется при переходе на новую систему работы. Представьте: есть продажник, кладовщик, закупщик. Продажнику звонит клиент, который спрашивает про «белые кружечки с каким-нибудь рисунком». У продажника есть какая-то программка, в которой он записывает, что у него есть, сколько оно стоит, какой клиент что заказал, то есть он каким-то образом ведет свою базу данных и работает с ней. Он звонит на склад и спрашивает про «какие-нибудь белые кружки с рисунком». Кладовщик открывает свою программку. И даже если в ней будет записано «кружка белая, 0,2 литра с рисунком тигр полосатый на желтом фоне», он человек и понимает, что то, что у него попросил продажник, и то, что он видит эту надпись перед собой, – это в принципе одно и то же. Ведь он человек, он может делать выводы и понимать.
А когда мы засаживаем всю компанию в единую систему, и начинаем работать через компьютер, то сталкиваемся с тем, что компьютер понимать не умеет. Компьютеру нельзя объяснить, что клиент хочет белую кружечку с рисунком, он по такому запросу ничего не покажет. Он хочет, чтобы ему точно сказали, чего вы от него хотите, желательно дословно по каким-то характеристикам, потому что он не человек и не умеет самостоятельно интерпретировать поступающую информацию. Люди это осознают только тогда, когда ударяются об эту проблему.
И многие с удивлением узнают, что им нужно каким-то образом формализовать общение, то есть договориться о терминах, о названиях, о том, кто эти названия дает, выработать какие-то правила, как он эти названия дает. Потом эти правила надо довести до всех, чтобы все остальные понимали, что и как может быть названо в каталоге. Мы же понимаем, что «белая кружка» и «кружка белая», если будут такие названия, – это принципиально разные вещи, они даже в разных концах алфавита находятся. И если у меня клиент попросил «белые кружечки с рисунком», и я прямо так попытаюсь найти это в каталоге, я этого не найду, но это вовсе не означает, что у меня этого нет.
Какие из этого возникают последствия, многие из вас знают. В разной комбинации маразма и количественного использования, но они были у всех.
Еще один класс проблем автоматизации связан с тем, что поскольку компьютерная реальность необъективна и генерится на основании наших документов, мы понимаем, что если кто-то обнаружил свою ошибку месячной давности и поправил ее, то все может резко измениться. Ведь каждое следующее действие система делала, основываясь на некоем состоянии, которое было тогда, когда она это действие совершала. А если кто-то вернулся на машине времени в прошлое и состояние перещелкнул, все остальные документы остались в томже состоянии как и были. Но теперь это состояние вполне может стать невправльным, так как система обрабатывала эти документы основываясь на том состоянии, в котором она находилась в тот момент, когда мы их делали. И теперь все стало неправильно. Это означает, что если мы обнаружили какую-нибудь ошибку, особенно где-нибудь в товарных остатках или деньгах, месячной давности, то половина всех движений с этого момента по сегодняшний день может быть неправильными. И получается, что одна ошибка сразу превращается в две-десять-сто, а может, и миллион – в зависимости от размеров базы и что конкретно это была за ошибка. И проблема в том, что разработчик даже не знает, что она появилась, потому что чуть-чуть подправить может кто угодно, что угодно и в любой момент. Поэтому если на предприятии нет определенных правил заведения классификаторной информации (контрагентов, номенклатуры), причем правил, которые введены до того, как в базу начали заносить данные, то гарантированно через месяц в базе будет куча однотипной информации, дубликатов, сочетающихся друг с другом, по три-пять-семь копий одной и той же номенклатуры, которая физически представляет из себя одно и тоже, но названо все по-разному: по-русски, по-английски, с точками и без точек, слова местами поменяны, еще как-нибудь.
И в результате то, ради чего затевалось использование системы, клиент не получает. Причем даже если система работает, строит какие-то отчеты, никогда нельзя быть уверенным, что картина, которую представил компьютер, адекватна, что на самом деле так и есть. Как бы вы ни контролировали, ни пугали и ни штрафовали, глядя на отчет, ему верить нельзя.
И получается вот такой ужас. Причем, иногда отчет даже вроде бы похож на правду, но вот правда ли это – неизвестно.
Как контролировать действия пользователей
Самое главное: что же со всем этим делать?
Первая из вещей, которая сильно облегчит жизнь: хотя бы для справочников контрагентов и номенклатуры (для основных документов) до того, как данные будут попадать в систему, нужно определить список простейших требований, что есть правильный документ, что есть правильно оформленная карточка контрагента, что есть правильная карточка номенклатуры. Потом надо поставить барьер, который отделит попытку записать эту карточку, внести ее в систему, в неточном варианте.
Здесь речь идет о том, как пользователь будет заполнять карточку, удобства для него, какие-то там обработки занесения и загрузки из Excel, формирования на основании предыдущих документов и т.д. и т.п. Все это, конечно, хорошо, но это благотворительность, это все надо оставить на потом.
Первоначально нужно поставить барьер на том, что именно пользователь пытается запихнуть в базу данных, как он это забивал – это оставьте на потом. Но многие почему-то начинают с того, чтобы принести пользу именно пользователю в процессе его вбивания чего-нибудь в систему. Но как раз это не польза, а всего лишь - красота и бантики. А нам на первом этапе важно не дать пользователю засунуть в базу бардак: он либо заносит информацию правильно, хотя бы с набором неких простейших наших правил, либо вообще ничего не может туда вписать. Пусть лучше он совсем ничего не запихнет, подойдет к технарю, который ему объяснит, что и как делать, чем в базе появятся неверные данные, и никто об этом не узнает.
Второе. Если человек может эмпирически определить, какая информация в базе ошибочна, то машина многое из этого сделать не может. Тем не менее, есть достаточно много вещей, которые можно проконтролировать, и это можно автоматизировать. Например, должны быть заполнены определенные поля. Они либо все заполнены, и тогда это попадает в систему, либо мы не даем ничего занести в систему. Ведь система гибкая, она позволяет и дает возможность заносить все, что угодно. Но этого нам не надо, нам надо, чтобы попадало только так, как принято в компании. Поэтому надо поставить между человеком и системой барьер. Определить эти вещи и их формализовать. Это убережет от невероятной кучи проблем в будущем, потому что каждая такая мелочь потом превращается в снежный ком.
Третье, о чем нужно подумать, и о чем обычно не думают. Когда система программируется, разрабатывается, все думают, как должно быть, как надо, как это обычно делается на предприятии. Например, вносить такой-то документ надо таким-то образом, он поступает обычно из определенных источников, его забивает обычно вот этот работник таким-то способом. Но не менее важно, чтобы технически было отрезано то, чего делать не нужно. На самом деле всегда существует несколько вариантов, которых ни при каких обстоятельствах быть не должно. Правильно только так, и иных вариантов быть не должно. И важно сделать так, чтобы все страшные варианты, заведомо неправильные, которые можно вычислить логически по формуле, отсеивались сразу. Например, отрицательных остатков на складе быть не должно, и при попытке запихнуть туда любые данные считаем остатки на конец рассчитанных итогов, и если в результате этого движения получается меньше нуля, то отменяем транзакцию и выдаем пользователю ругательство. Нельзя сделать приход, потом расход, а потом вернуться и приход отменить. Пусть пользователь сам не сможет исправить обнаруженную ошибку и пойдет к технарю, а уже тот сделает исправление правильно, с учетом все последствий. Но допускать, чтобы в системе был заведомо ложный результат, нельзя.
И последний момент. Достаточно большое количество действий в системе логически последовательны: если в поле А выбрано это, то в поле Б может быть только это. Например, если мы выписываем реализацию от нашей компании, которая ООО, на эту реализацию всегда делаем счет-фактуру. Если мы выписываем реализацию от нашей компании, которая ИП, то счет-фактуру к реализации выписывать не надо никогда. Здесь есть некая логика, причем четкая и все данные для принятия решения по этой логике в системе есть. Из таких действий желательно человека убрать вообще, не надо ему давать доступ к кнопочке «сформировать счет-фактуру» совсем. Спрятать ее, чтоб он ее даже не видел. Провели реализацию – сделалась счет-фактур, поменяли компанию – удалилась, поменяли обратно – сделалась счет-фактура, отменили – отменилась. То есть в такой логике, которая должна быть и есть, человеку делать нечего. Ему нечего делать в зале, заполненном роботами.
И напоследок небольшие рекомендации.
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER.
