Помощничек
Главная | Обратная связь


Археология
Архитектура
Астрономия
Аудит
Биология
Ботаника
Бухгалтерский учёт
Войное дело
Генетика
География
Геология
Дизайн
Искусство
История
Кино
Кулинария
Культура
Литература
Математика
Медицина
Металлургия
Мифология
Музыка
Психология
Религия
Спорт
Строительство
Техника
Транспорт
Туризм
Усадьба
Физика
Фотография
Химия
Экология
Электричество
Электроника
Энергетика

Классификация проблем с точки зрения компании ЭОС



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

Проблема первая. «Излишнее наукообразие»

Итак, проект начинается, и начинается он с консалтинговой «классики» с обследования и описания бизнес-процессов, подлежащих автоматизации. Именно здесь, на старте проекта, внедренцы зачастую допускают ошибку, которая закладывает мину замедленного действия под весь процесс внедрения. Речь идет о широко распространившейся практике формализованного описания бизнес-процессов с использованием нотаций типа IDEFx, ARIS или UML. Нельзя отрицать принципиальную полезности инструментов такого рода в крупных проектах, предусматривающих разработку или настройку сложных программных систем. Однако применение формальных нотаций в проектах по автоматизации ОРД — когда речь идет, как правило, о подстройке типового программного продукта под особенности процессов документооборота конкретного заказчика — можно охарактеризовать давно знакомым и родным «из пушки по воробьям».

Проблема вторая. «Сопротивление среды и реинжиниринг наоборот»

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

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

Проблема третья. «Монстр кастомизации»

Большинство известных автору проектов внедрения СЭД, потерпевших неудачу, «умирали», не вынеся тяжести дополнительной прикладной разработки, которую внедренцы пытались взгромоздить поверх базовых средств системы. В кастомизированном интерфейсе только одно хорошо — он внешне выглядит так, как хочется заказчику. Все остальное в доработке плохо. Исходная система становится менее стабильной, поскольку качество кастомизационного программного кода уступает базовому коду. Производительность исходной системы падает, ведь дополнительный код является надстройкой над базовым кодом, что приводит к неизбежным издержкам времени исполнения программы. Проект внедрения становится гораздо более дорогим. Если проанализировать бюджет типичного проекта внедрения СЭД, легко заметить, что на кастомизацию уходит от 50 до 80% всего бюджета.

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

Проблема четвертая. «Недопроект»

Некоторые полагают: «Подумаешь, движение и учет бумажек автоматизировать... Зачем управляющий комитет проекта создавать, бизнес-спонсора назначать, вести все работы по «взрослой» проектной методологии? Руководить проектом поставим начальника канцелярии, в помощь ей выделим системного администратора – все равно целыми днями в серверной просиживает. Глядишь, за месяц управимся». Никто из руководителей подобных монологов не произносит. Но вот действия и руководящие решения, принимаемые во многих компаниях в части СЭД, являются наглядной иллюстрацией отношения к проектам автоматизации процессов организационно-распорядительного документооборота как к чему-то второстепенному.

 




Поиск по сайту:

©2015-2020 studopedya.ru Все права принадлежат авторам размещенных материалов.