Наверх

Способы поставить задачу и средства взаимодействия в ECM

Время чтения: 4 минуты
0
Способы поставить задачу и средства взаимодействия в ECM

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

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

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

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

Во-первых, есть пресловутые горизонтальные связи. Любой любому ставит задачу и контролирует исполнение. Многие системы (и западные в первую очередь) — будь то ECM, ERP, CRM, CMS и порталы — содержат в себе средства выдачи и контроля простых задач. Для небольших компаний, проектных групп и других плоских структур это очень удобно, но недостатки тоже имеются. Сложно выставлять приоритеты задач (чью вперед выполнять — начальника или коллеги по интересному проекту?), появляются "узкие места" (сотрудники, которые нужны всем, которых загружают без меры и которые на всё соглашаются), появляются "отказники" (люди, которые ничего не исполняют, пользуясь тем, что или их область ответственности определена нечетко, или тем, что какой-то особой силы ни одно поручение не имеет).

Во-вторых, есть процессный подход. Он не исключает ни командно-административной схемы, ни горизонтальных связей, но позволяет снизить их долю. Если процесс идет по правилам (по заранее определенной схеме), то решение будет принято верное. Работает далеко не для всего, но, повторюсь, долю других механизмов снижает. Надо ли говорить, что автоматизация таких процессов — одна из первейших задач ECM?

В-третьих, есть постановка задач в ситуации, когда у одного сотрудника несколько начальников. Даже если рассматривать простейшую матричную систему, организованную по принципу "проект-функция", то видно, что есть руководитель-"функционер", а есть руководитель проекта (а у каждого руководителя еще и своя иерархия). И поручения приходят от каждого. При грамотном распределении ответственности в матричной оргструктуре приоритеты поручений сотрудником определяются довольно просто. Однако я практически не видел, чтобы ECM-системы помогали бы формировать и ранжировать список входящих задач с позиции "проект / функция". Разве что автоматическая сортировка по папкам или разные списки входящих.

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

В-четвертых, есть горизонтальное взаимодействие в очень крупных компаниях, которое решается уже социальными инструментами. Если число уровней в иерархии составляет 6-7, то любое решение, требующее организации работы нескольких подразделений (и особенно если они находятся в разных уголках страны или планеты), будет приниматься очень долго. А простые инструменты постановки произвольных задач не спасают: банально непонятно, кто обладает нужной компетенцией в том или ином вопросе, кто обладает полномочиями, кто заинтересован в этой работе. Возникают структуры, параллельные регламентированной оргструктуре, этакие "сообщества по интересам" или "сообщества по теме". Вот здесь ECM-вендоры начинают проявлять активность, осторожно предлагая E2.0-инструментарий.

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

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 0

Чтобы прокомментировать, или зарегистрируйтесь