Участник:ArmorAdmin/Управление заданиями — различия между версиями

Версия 14:31, 30 июня 2010

Автор(ы): Чобиток Василий, 11 ноября 2006

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

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

Что же делать в такой ситуации? Как исполнение документов, заданий, поручений поставить на поток? Как в любой момент времени знать, какую задачу, когда и кто выполняет, не забывать о ней, вовремя реагировать на возникающие у исполнителя проблемы?

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

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

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

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

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

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

Успешность работы «софта» в организации на 20% определяется функциями и возможностями самого ПО и на 80% – правильной организацией работы с ним. Если вы не умеете фотографировать, Photoshop не виноват, что ваши фотографии неинтересны; если вы не инженер-механик, никакой CAD не поможет сконструировать новый нетиповой шестеренчатый механизм; если вы не художник... не писатель... не...

Дальше перечислять? Так почему же мы, не освоив элементарных приемов управления и отслеживания исполнения задач и документов, всегда с энтузиазмом бросаемся автоматизировать эту сложную сферу деятельности, еще не поняв «что мы хотим», но, уже зная «как это сделать»?

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

Прежде чем перейти к дальнейшему изложению, определим два понятия.

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

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

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

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

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

Что нужно, чтобы задачи, которые уже не теряются, исполнялись в определенной последовательности, в порядке приоритета, осмысленно, в срок и во взаимодействии с другими сотрудниками? Ответ очевиден: организовать процесс исполнения поручений и заданий. Менее очевиден ответ на вопрос, каким этот процесс должен быть.

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

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

Принципом вашей дальнейшей работы должен быть следующий: задача, поставленная исполнителям устно и не зафиксированная в системе документооборота, не существует.

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

Вопрос собственной разработки может показаться достаточно простым. В самом деле, что ж тут сложного? Зарегистрировать задачу, назначить для нее исполнителя, определить дату и приоритет исполнения и ожидать, когда же он кликнет кнопку «исполнено» в окне описания задачи... В реальности все не просто сложнее, а намного сложнее!

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

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

Регистрация. Руководитель вносит задачу в систему, при этом:

• Задаются атрибуты задачи (тема, описание, общие планируемые трудозатраты, срок выполнения и т.д.)

• Определяется список исполнителей. Здесь необходимо решить, как обрабатывать задачу с несколькими исполнителями, как одну, как несколько по числу исполнителей, или одну с вложенными, подчиненными задачами. Мне представляется оптимальным последний вариант.

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

Кроме того, хотите ли вы общаться со всеми исполнителями, которых привлекли начальники отделов, или вам, как руководителю, важно общаться по задаче c тем кругом лиц, который определён изначально? Этот вопрос также накладывает некоторые ограничения на реализацию системы.

• Задается приоритет выполнения. Понятно, что срочные, критические задания должны выполняться в первую очередь и система должна иметь информацию о приоритете задач и уметь сортировать задачи по приоритету в порядке убывания.

• Задается тип задачи или информации. Тип задачи определяет с использованием какого бизнес-процесса (алгоритма) будет происходить исполнение задачи.

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

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

Привлечение новых исполнителей и делегирование. Может ли исполнитель привлекать к исполнению поставленных ему задач своих подчиненных? Ответ зависит от конкретной задачи, а так же от принятого в организации порядка обработки заданий. Например, если вы поставили начальнику IT отдела задачу отсканировать и распознать документ, состоящий из 100 листов, вполне естественно, если он выполнит эту задачу не собственноручно, а поручит одному из своих подчиненных (например, оператору ПК). В то же время, будет глупо, если на переговоры с руководителем IT департамента другой организации начальник IT отдела пошлет вместо себя того же оператора. Таким образом, система должна позволять руководителю решать может ли исполнитель привлекать новых исполнителей задачи или должен выполнить ее сам (например, вводом атрибута задачи «исполнить лично»).

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

Прием к исполнению и выполнение. Достаточно ли зарегистрировать задачу и считать, что исполнитель ее сразу же исполняет? Наивно полагать, что обязать пользователей системы периодически просматривать список своих задач будет достаточным для того, чтобы они оперативно получали информацию о новых заданиях. Во-первых, пользователь должен быть оперативно проинформирован о новой задаче и, желательно, автоматически (E-mail, ICQ, SMS и т.п.). Во-вторых, пользователь может по каким-либо причинам не иметь возможность исполнить поступившую в установленные сроки задачу, поэтому должен иметь возможность вернуть задачу с пояснением причин. Например, новое задание, назначенное к исполнению на завтра, может быть отклонено т.к. исполнитель отбывает сегодня в командировку.

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

Закрытие задачи. Можно ли считать, что пользователь, доложивший о выполнении задания, на самом деле его выполнил? Есть ли необходимость руководителю проверять выполнение поставленного задания? На эти вопросы так же можно дать разные ответы.

Например, скорее всего, нет необходимости забивать себе голову контролем выполнения задачи вроде «ознакомиться с таким-то документом, принять к сведению». Если исполнитель помечает эту задачу как исполненную, так пусть она сразу же попадает в архив и не мозолит нам глаза.

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

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

Кроме того, можем ли мы закрыть задачу, по которой есть невыполненные подчиненные задачи?..

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

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