План это документ! Правильный документооборот

Вид материала

Решение

Содержание План это документ! Правильный документооборот. Электронное делопроизводство Электронный документооборот (docflow) Управление рабочими процессами (workflow) СЭД при применении: отдельная система или подсистема? Типичные ошибки при решении проблем с негибкой подсистемы управления бизнес процессами (BPM). СЭД в роли BPM. Выгоды применения СЭД для поддержки бизнес планирования. Работа со всеми данными в системе в разрезе бизнес – планирования. Полный контроль за исполнением бизнес – плана. Проблематика применения СЭД для решения задач управления бизнес планированием. Неправильная постановка задачи. Любительский подход. Человеческий фактор.

Подобный материал:

• Это движение документов в организации с момента их создания или получения до завершения, 1435.6kb.
• Бизнес план это > Документ внутренней отчетности Документ являющийся основанием для, 101.74kb.
• План работ по совершенствованию делопроизводства, 136.55kb.
• Данный документ содержит материал двух статей Методы управления документооборотом, 372.36kb.
• Стратегический план социально-экономического развития городского поселения город лебедянь, 1385.81kb.
• «Россия: ценности современного общества» инсор, 993.55kb.
• Электронный документооборот для "Электронной России", 38.7kb.
• Тесты по праву для 10-11 классов для выполнения заданий 1 час 20 минут. Только один, 130.99kb.
• Бизнес-план инвестиционного проекта это предназначенный для участников проекта структурированный, 769.62kb.
• Планирование объема производства в натуральном и денежном выражении 12 Резервы увеличения, 271.38kb.

Поддержка бизнес процессов в компании в системах электронного документооборота:

Богодский Владимир, Коммерческий директор компании «Евроменеджмент».

• Автоматизация бизнес планирования – зачем это нужно?
  
• План – это документ!
  
• Правильный документооборот.
  
• СЭД при применении: отдельная система или подсистема?
  
• Типичные ошибки при решении проблем с негибкой подсистемы управления бизнес процессами (BPM).
  
• СЭД в роли BPM
  
• Выгоды применения СЭД для поддержки бизнес планирования.
  
• Проблематика применения СЭД для решения задач управления бизнес планированием.
  

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


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

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

План это документ!

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

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

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


Если посмотреть на предъявляемые требования, наиболее полно всем им соответствуют только системы документооборота последнего поколения.

Правильный документооборот.

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

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

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

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

Управление рабочими процессами (workflow) – в переложении на СЭД, это такие СЭД, которые могут обеспечивать хранение и обработку информации о бизнес - объектах, используемых в бизнес-процессах. Ключевым отличием СЭД workflow класса от СЭД уровня docflow является использование понятий в системе «бизнес - объект» (структурное подразделение в компании) и «бизнес – процесс» (маршрут) как базовых, основополагающих. Особенностью такой ориентированности системы является то, что в рамках одного рабочего процесса могут обрабатываться различные документы, а сама система СЭД workflow может выступать как единая магистраль для интеграции различных бизнес-приложений. Плюс такая система сможет обеспечить контроль выполнения (исполнения) поставленных в изменяемом электронном бизнес – плане задач через встроенные в такую СЭД механизмы контроля и согласования, присущие всем современным СЭД уровня docflow и выше. Исходя из вышеперечисленных возможностей, системы workflow-класса являются наиболее широкими по своим возможностям, позволяя, в том числе, реализовать функции как стандартных систем документооборота, так и систем управления документами. Подобных систем на рынке – меньшинство, но именно выполняемые ими (подобными системами) функции являются, на сегодняшний день, всё более востребованными.


Таким образом, следуя приведённой выше классификации стоит чётко разделять системы электронного документооборота по сфере их применения. К примеру, система делопроизводства служит только как хранилище документов и средство совместной работы над документами – не более того. Для небольшой компании с преимущественно регламентирующей документацией такой системы будет вполне достаточно. Но для средней компании с, например, сложными производственными процессами, такой системы для налаживания автоматизированных процедур электронного документооборота будет явно мало. Более того, для подобных средних компаний, как и почти для всех крупных компаний негосударственного типа и\или компаний с распределённой структурой не во всех случаях подойдёт даже система dokflow класса. Для оперативного управления компаниями такого уровня уже необходимо внедрять СЭД workflow класса, в виде отдельного продукта с интеграцией с прочим корпоративным ПО, либо в виде подсистемы в корпоративной системе ERP класса.

СЭД при применении: отдельная система или подсистема?

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

Настоящая статья посвящена описанию воплощения бизнес стратегии предприятия посредством выражения процедур и действий через систему электронного документооборота, как наиболее полно охватывающее подобную задачу и обеспечивающую наиболее полную интеграцию автоматизации задач поддержки и управления бизнес планированием с прочими задачами в компании. Поэтому, описывать автоматизацию процессов исполнения и поддержки бизнес плана компании через подсистему документооборота корпоративной ERP системы не является раскрытием подобной тематики: в подавляющем большинстве случаев, подсистемы электронного документооборота в таких «тяжёлых» системах (например MS Axapta, SAP и т.д.) выражают базовую логику (и так называемую «философию») самой системы ERP, служа лишь вспомогательным механизмом решения «узкой» задачи автоматизации документационного управления, а именно: хранения, пересылки и совместной работы. В редких случаях, например, в MS Axapta, есть полнофункциональная подсистема WORKFLOW с возможностью раздельного управления распределёнными центрами ответственности (по сути, обособленных подразделений компании, к примеру, цехов). Но данные подсистемы всё равно выражают только ПРОЦЕССНОЕ управление (как линейное, так и дискретное) и не являются интерактивными механизмами поддержки работы именно собственных задач бизнес планирования.

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

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

Типичные ошибки при решении проблем с негибкой подсистемы управления бизнес процессами (BPM).

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

Некоторые компании не изменяли саму ERP систему, но вносили изменения в регламентирующие действия собственных сотрудников. Например, назначением в обход самой системы, некоторых исполнителей. Либо же выражали какие-либо внутренние процессы на предприятии через наиболее похожие документы и процессы, заложенные в системе. Так начали появляться внутренние документы на согласование, имеющие гордое наименование в «шапке» документа: «Заявка на техническое обслуживание» и тому подобные несоответствия. Итог всех таких действий был, как правило, одинаков: пока количество и масштаб подобных «изменений» был невелик, пользователи могли мириться с таким положением дел. Но чем дальше, тем больше сама система превращалась из удобного инструмента поддержки бизнеса в некоего монстра, пожирающего ресурсы и время для, порой, достаточно рутинных повседневных операций. Автор статьи лично знаком с несколькими подобными компаниями. В частности, в одной из таких компаний есть даже утверждённый порядок адаптации нового сотрудника: новичка несколько недель в обязательном порядке учат как «правильно понимать» корпоративную систему, пусть данное «понимание» и идёт вразрез с нормальной логикой; что необходимо сделать в случае того и другого, при ситуации, когда сама система не «закрывает» какого-нибудь участка работ. В таких вопиющих случаях не приходится говорить не только о поддержке корпоративной системой ведения и исполнения бизнес – плана компании, НО ДАЖЕ И О НОРМАЛЬНОЙ АВТОМАТИЗАЦИИ ПРЕДПРИЯТИЯ, в целом. Конечно, автор отмечает, что приведённый пример не совсем типичен – подобное положение дел скорее крайность, нежели обычное положение дел для подобных компаний. Но и в обычной для подобных компаний, ситуации проблемы с работоспособностью корпоративной системы управления, особенно в части бизнес планирования хоть и не так ярко выражены, но также присутствуют. То обстоятельство, что имеющие место проблемы не так бросаются в глаза и пользователи системы, как сотрудники, так и само руководство компании, привыкают к сложившемуся положению дел, не уменьшают самих подобных проблем.


Другие компании пошли иным путём: внедряя в дополнение к корпоративной системе ERP (путём интеграции) или же устанавливая отдельно специализированное ПО, ориентированное на оперативное управление бизнес – процессами (BPM, Business Plan Management). Однако, установленное отдельно данное ПО не является полнофункциональным РЕШЕНИЕМ для управления бизнес планированием на предприятии: BPM системы полезны, в первую очередь, для планирования и анализа результатов стратегического и тактического управления, но не для донесения необходимых действий до исполнителей и т.п. То есть, моделировать и оперативно применять бизнес схемы в виде схем, графиков и т.п. для руководства стало возможным, но применить данные схемы (донести до исполнителей и проверить сам факт и качество исполнения) в отдельно установленной (без связи с внешним ПО) BPM системе нельзя. В том случае, когда BPM система устанавливается в виде интегрированного с другим ПО в компании (например, совместно с полнофункциональной ERP системой), также возникает ряд сложностей. Во-первых, если подобная интеграция проводится на базовом (минимальном) уровне, функционал самой системы BPM при переносе данных (и соответственно обратном импорте) становится, в значительной степени, урезанным. На деле это выглядит так: например, графики и диаграммы отчётов переносятся в ERP из BPM только в виде вложений – являют собой статичное изображение. Такой информацией можно пользоваться только чтобы донести актуальную, на момент переноса из одной системы в другую, картину, не более того. Во втором рассматриваемом случае – более полная интеграция – точек сопряжения обоих систем количественно и качественно больше. Но и тут есть свои неприятные стороны: глубокая интеграция несёт в себе достаточно большие затраты, как ресурсные (время, человеческий ресурс), так и гораздо более высокие риски – порог их становится опасно высок для оценки потенциальной успешности такого проекта интеграции разнопланового ПО – примеры подобных проектов единичны и в каждом случае глубоко индивидуальны. И это не говоря снова о том, что созданная, интегрированием минимум из двух систем, корпоративная информационная система становится гораздо более громоздкой и негибкой даже в сравнении с теми же параметрами в случае создания механизмов поддержки бизнес процессов «внутри» ERP системы. Ведь в случае внесения любых существенных правок в любую из составляющих систем (ERP и BPM), необходимо будет внести соответствующие корректировки и в другую. Иначе сопряжение двух этих (а иногда и более!) систем будет нарушено.

СЭД в роли BPM.

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


Именно такие системы электронного документооборота, относящиеся по приведённой выше классификации СЭД, к системам WORKFLOW класса, стали решением подобной задачи.

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

Выгоды применения СЭД для поддержки бизнес планирования.

Динамичный, встроенный во все процессы в компании, бизнес – план.

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

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

Работа со всеми данными в системе в разрезе бизнес – планирования.

Вторым важным преимуществом использования СЭД систем класса WORKFLOW является то обстоятельство, что анализ текущего исполнения бизнес – плана опирается на оперативные данные внутри системы, в отличие, например, от случая применения отдельной системы BPM, интегрированной в корпоративную информационную систему. Ведь для настроек интеграции BPM невозможно предоставить все данные, содержащиеся в «большой» корпоративной системе. В случае же работы в СЭД WORKFLOW бизнес – план и выраженные в нём бизнес – процессы работают напрямую со всей актуальной информацией. Что открывает очень большие горизонты: качественно и количественно больший набор аналитик и степеней детализации – для принятия управленческих решений руководством, прозрачность процессов и видение самих процессов не только в масштабе собственных задач для линейных руководителей. И, наконец, для рядового исполнителя появляется возможность выполнять возложенные на него задачи более качественно: при отлаженном переносе решений бизнес планирования в выраженный план дел и текущих личных задач. Плюс к этому, для каждого исполнителя расширяется горизонты: теперь он не просто «винтик» внутри некоей «машины» компании, который не имеет представления о всём процессе, в целом. Исполнитель может видеть, по необходимости и правлиной настройке доступа, доступный ему участок работы в связке с соседними и\или смежными процессами. Помимо более глубокого понимания своих задач, каждый исполнитель становится более лоялен и к самой компании – он уже чувствует себя самого как часть общего «процесса».

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

Полный контроль за исполнением бизнес – плана.

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

Проблематика применения СЭД для решения задач управления бизнес планированием.

В заключение придётся добавить ложку дёгтя в описанную картину использования автоматизированных систем поддержки бизнес планирования посредством СЭД систем класса WORKFLOW. Вернее, даже несколько. Проблематика при установке и применении таких СЭД достаточно типична – также как и при внедрении и использовании любого достаточно сложного ПО. А именно: неправильная постановка и, соответственно, решение поставленных задач, любительский подход, состояние рынка СЭД WORKFLOW и, наконец, пресловутый человеческий фактор. Давайте разберём каждый из них по отдельности.

Неправильная постановка задачи.

Зачастую, приглашённый аутсорсер (компания, занимающаяся внедрением) совершает две основных (для клиента) ошибки, а именно: подходит к решению с технической стороны дела. То есть делает всё, что говорит и не делает то, о чём её не просил, либо не сумел донести заказчик. Это, в первую очередь связано с тем, что подобная картина складывается, как правило, в том случае, когда аутсорсер является, в основном или только, разработчиком собственного ПО, а не консультантом по планированию. Грамотный партнёр по внедрению (компания - аутсорсер) всегда помогает заказчику не только провести автоматизацию уже существующих процессов, но и в первую очередь, оптимизировать сначала сами имеющиеся процессы. Конечно же окончательное решение всегда остаётся за заказчиком, но снижение затрат при автоматизации уже оптимизированных процессов выгоднее: не автоматизируется лишнее (было убрано на этапе автоматизации), эффективность процессов отлаженных заранее, а не на этапе функционирования системы соответственно выше. В итоге, снижаются и сами сроки внедрения за счёт более чёткого понимания сторонами всех возникающих задач в рамках общей задачи. При применении подобного комплексного подхода риски проекта внедрения снижаются многократно.

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

Любительский подход.

Более чем в половине случаев внедрения заказчик, что естественно, старается сэкономить на услугах внешнего партнёра. Другими словами, провести автоматизацию своими силами. В некоторых случаях это является оправданным – для компаний с достаточно несложными бизнес – процессами и\или небольшого масштаба это даже оправдано. Именно для таких компаний практически все крупные разработчики выпускают так называемые «коробочные» версии своего ПО – по сути, упрощённых, стандартизированных версий разрабатываемого ими же решения. Эти решения специально подготовлены для самостоятельной установки и настройки непосредственно заказчикам. Естественно, сразу возникает вопрос: как отличить сложные задачи от простых? Когда возможно использование «коробочных» продуктов, а когда необходимо привлечение сторонних специалистов? Ответ непрост и в каждом случае индивидуален. Единственной рекомендацией может служить только пожелание обращаться в любом случае к консультантам компании разработчика или аутсорсера: известные и проверенные временем компании дорожат своей репутацией и всегда дают предельно корректный ответ – стоит ли использовать «коробку» или требуется внедрение с привлекаемыми силами стороннего партнёра.

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

Состояние рынка СЭД WORKFLOW.

Наиболее завуалированная проблема. Несмотря на значительное существующее предложение рынка СЭД в России, системами, на самом деле являющимися системами класса WORKFLOW являются буквально единицы. Называть эти системы я намеренно не стану, чтобы не быть обвинённом в рекламировании некоторых и намеренном принижении достоинств остальных. К тому же, утверждённых наборов признаков, по которым можно было бы чётко разделить все СЭД по классам, в России нет. Что же касается критериев оценки – я привёл их выше. Порекомендовать можно лишь одно – внимательно присматривайтесь к предлагаемым вам решениям от разных производителей, не стесняйтесь спрашивать об уже внедрённых решениях и, конечно же, выбирайте систему наиболее полно решающую именно ваши задачи, а не ту систему, которая внедрена в известных компаниях или же обладает наибольшим количеством наград и призов.

Человеческий фактор.

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


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