Вредные мысли от Алана Купера

Александр Дублин

Вредные советы для внедренцев ERP


Александр Дублин 7 сентября 2011, 16:20

 

Вредные мысли от Алана Купера

«У компаний есть отличная возможность сдвинуться с мертвой точки и сосредоточить усилия на:

- удовлетворении потребностей клиентов, а не на программах,

- на персонажах, а не на технологиях,

- на выгоде, а не на программистах».

(Алан Купер «Психбольница в руках пациентов, илипочему высокие технологии сводят нас с ума и как восстановить душевное равновесие»)

 

Танцующий медведь

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

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

Потребитель ERPсистемы - не только пользователь, но персонаж!

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

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

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

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

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

Ключ к решению

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

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

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

Мало дружественного интерфейса, необходимо эффективное взаимодействие

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

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

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

Мне нужна газонокосилка!

Что можно сказать хорошего о функциях? Они поддаются измерению. И это свойство измеримости придает им ауру ценности, которой в действительности они не обладают. Отрицательные качества функций полностью съедают все их положительные качества. Функции - причина одной из серьезных проблем проектирования, потому что каждая возможность, предложенная из лучших побуждений и потенциально полезная, оттеняет некоторые возможности, которые, вероятно, будут действительно полезны. Разумеется, реализация возможностей не бесплатна. Каждая из них усложняет ERP систему. Они требуют увеличения размера и сложности документации и системы контекстной справки. Что важнее всего: стоимость внедрения этих монстров уже многократно превышает стоимость самого программного обеспечения, они требуют раздувания штата технической поддержки, занятого в консультировании пользователей относительно этих самых возможностей.

Для нашего зациклившегося на функциях мира мысль, наверное, непривычная - вы не достигнете своих целей, используя набор функций как инструмент. Можно замечательно реализовать все функции из утвержденного набора и все равно попасть в беду. Для доказательства этого тезиса проектировщик взаимодействий Скотт Мак-Грегор на своих занятиях использует вот такой замечательный тест. Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет: 1) двигатель внутреннего сгорания; 2) четыре колеса с резиновыми покрышками; 3) трансмиссия, связывающая двигатель с ведущими колесами; 4) трансмиссия и Двигатель смонтированы на ходовой части; 5) рулевое колесо. На этот момент времени каждый слушатель уже записал, что это автомобиль, но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя: 6) быстро и легко срезает траву; 7) на этом удобно сидеть. На основании пяти функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка. Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.

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

Скрестим пальцы и скажем: «Удачи!»

← Назад