Журнал о системах электронного документооборота (СЭД)
Взаимодействие и групповая работа

Почему так слабо используются инструменты управления задачами?

  14 комментариев Добавить в закладки

В этой заметке нет ответа. Есть вопрос.

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

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

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

Но все равно подобные решения не становятся массовыми и продаются скорее за кампанию с прикладными решениями.

Теоретические словоблудие

Я попытался как-то системно понять есть ли потребность, но похоже оторвался от земли. Получилось такое…

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

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

Для информационного работника основной формой деятельности является выполнение разрозненных задач. Задачи могут появляться в рамках проектной деятельности, функционирования бизнес-процессов, исполнений кейсов или могут быть произвольно сформулированы коллегами и руководством. Кроме того, сам сотрудник ставит себе задачи, упорядочивая собственную работу.

Задачи – это способ организации работы информационного работника. Какие есть возможности для повышения производительности труда:

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

Таким образом можно сделать теоретический вывод о существовании фундаментальных потребностей в управлении задачами.

Практическая часть

На западном рынке есть целый самостоятельный класс систем для управления задачами. Яркие представители: ИТешная Jira, Asana от выходцев из Фейсбука, популярный Todoist, модный GetFlow и еще с десяток решений от облачных потребительских, до могучих корпоративных. И многие из них еще имеют тайм-трекинг, исповедуют GTD, работают на всем включая утюги и т.д.

Что у нас? Самостоятельных решений всего несколько и те крошечные по числу пользователей. В СЭД все это чаще заменяется на Франкенштейна под названием «Поручение».

Коллеги, что не так? Почему у нас это не работает? Не доросли просто? Уже используют, просто я не в курсе? Хватает узких решений, например, TFS + Project + Outlook как у меня на работе сейчас?

Максим Смирнов, ваше мнение особо интересно, ваш доклад по ACM лег в основу моего понимания вопроса :). Почему корпоративные пользователи массово не пользуются инструментами для управления задачами, а обходятся почтой? Или пользуются?

Ещё материалы автора
Похожие записи
Комментарии (14)
Рамиль Миннизянов 27 сентября 2014 г. 09:32  

Виктор, добрый день! 

Если судить по моему опыту - усредненная картина такая: на первом месте будет ментальность и привычка не брать на себя ответственность - это самый большой бич! 

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

Но все меняется очень быстро, если все-таки руководителя вовлечь в это и даже простой отчет об исполнительской дисциплине привязать к системе мотивации - все очень быстро начинают и использовать и принимать такую систему! :) 

 

 

Иван Коваленко 27 сентября 2014 г. 13:05  

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

Александр Сидоренков 28 сентября 2014 г. 16:33  
Что у нас? Самостоятельных решений всего несколько и те крошечные по числу пользователей. В СЭД все это чаще заменяется на Франкенштейна под названием «Поручение».

Виктор, здесь не очень понятен объект Вашей негативной оценки - "Поручение" как таковое или то как это в большинстве случаев реализовано в СЭД?

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

Коллеги, что не так? Почему у нас это не работает? Не доросли просто? Уже используют, просто я не в курсе? Хватает узких решений, например, TFS + Project + Outlook как у меня на работе сейчас?

Именно ИТ-компании достаточно активно используют перечисленные Вами продукты типа JIRA или Todoist, все остальные компании практически нет. Впрочем я думаю, что за рубежом все то же. Да и продукты для управления задачами, которые есть на рынке все-таки вышли из ИТ и для ИТ в первую очередь создавались. На мой взгляд для управления компанией подобные продукты не подходят.

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

 
Так почему же все это не работает. Выскажу свою точку зрения. Методологией (не путать с регламентами и положениями) в настоящее время почти никто не занимается. Все верят в технологии и отраслевые тренды, они же обычно и обсуждаются на различных ресурсах, в том числе и здесь. Многие новые ИТ-продукты для бизнеса сейчас создаются "мальчиками с горящими глазами", либо как,например, Asana для себя. В итоге получается очередная task management система очень похожая на десятки других, но более удобная с точки зрения того, кто ее создавал. Вот и получается, что для управления проектами продукты есть, а для управления компанией нет.

 

Виктор Золотов 28 сентября 2014 г. 17:33  

Поручения в СЭД хорошо решают поставленные задачи (и в Доксе и Директуме и прочих). задача простая - вертикальный жесткий контроль. При этом в подавляющем большинстве случаев поручения есть результат резолюции на входящий документ (иногда протоколы по совещаниям, ну и остальное по мелочам). В итоге они закрывают до 5% (а реально около 1%) от всех мыслимых задач (я прикидывал на 20 компаниях где ХОРОШО внедрена СЭД, анализируя данные в Exchange и СЭД, а также прикидывая сколько задач были сформулированы лично или через Lync). Рядовые сотрудники активно не используют не только поручения, но и задачи (что в Доксе, что в Директуме, что в других системах), хотя вроде там полей меньше и все удобно на первый взгляд. Только в рамках процессов жестко внедренных создаются задачи, а более и нет.  

По Мегаплану. Почитайте интервью директора: http://siliconrus.com/2014/04/not-about-services/

По ИТ-компаниям. Во-первых ИТ компании это как бы не весь рынок. Во-вторых я проанализировал 10 компаний из то-50 интеграторов. Будете смеяться - у них показатели НЕ лучше. Да, Jira приживается лучше, разработчики часто юзают TFS, у многих есть Project или аналог. Но 80% задач все равно в Outlook. Мой почтовый ящик с 1500 входящих писем в месяц типичный пример. Для контроля - Эксель (отчеты и все такое).

У вендоров СЭД, вот по другому, они молодцы ). Но их 5 штук.

Я вполне готов поверить, что проблемы нет - почта при всех ее минусах за решительным преимуществом удобнее, потому все ее используют. Но все таки западный опыт показывает что задачи могут быть самостоятельным и массовым продуктом. Чего уж далеко ходить, Докс вам близок, вот что скажете про их продукт: http://actionspace.com/ ? Они же не западный рынок выходят именно с этим продуктом... Я подробностей не знаю, может МС инвестировал или еще что-то в этом роде, но факт есть факт - продукт делают... 

Виктор Золотов 28 сентября 2014 г. 17:35  
мальчиками с горящими глазами

Александр, вы же не назовете разработчиков ActionSpace мальчиками с горящими газами? )

 

 

Виктор Золотов 28 сентября 2014 г. 17:41  
я прикидывал на 20 компаниях

Александр, что бы понятнее было, в это число попала одна строительная группа, где вы внедряли СЭД (как раз для поручений). Все поручения у них типа в СЭД. А представляете сколько у них задач вне поручений? От сложных (в рамках бюджетирования, согласования договоров...) до простого личного планирования и писем в стиле "Маша, закажи нам новый чайник!". На несколько порядков больше. 

 

 

Александр Сидоренков 29 сентября 2014 г. 16:08  

Виктор, предлагаю определиться с терминологией. У меня создалось стойкое ощущение, что Вы под "поручением" понимаете что-то для жесткой иерархии, необходимое в первую очередь для рассмотрения и исполнения входящего документа. А "задача" - это уже нечто современное, действительно живое, относящееся к реальной деятельности компании. Т.е. в СЭД сплошные "поручения", а в современных продуктах "задачи". Этот стереотип сейчас у многих.

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

В моей методологии это все четко выстроено. Базовой для компании является стратегия, которая декомпозируется на цели для сотрудников/подразделений, достигнув которые стратегия будет реализована. Цели реализуются с помощью проектов и задач, которые в свою очередь делятся на множество поручений. Это методология для автоматизации управленческой деятельности и ее задачи сильно отличаются от ИТ-шных tasks.

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

Виктор Золотов 29 сентября 2014 г. 16:54  

Да дело не в продуктах и поручениях, иерархиях и т.д. На западе кстати вертикальная иерархия это оксюморон, а проекты - это пример матричной структуры а не иерархической. Но да не в этом суть!!!

Вот смотрите, есть ДокументВижин (пускай так называется). Отличный продукт же. Вот задача в нем:

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

Почему нет вирусного эффекта, почему люди НЕ начинают слать себе задачки как на картинке? Я не про 50 штук в год и не про те задачи, что формируются автоматом насильно (их крохи поскольку). А сами себе и коллегам!

Почему этого нет? Система не та? Люди не те?

Вендор тоже ЭТО понимает и делает систему для ЗАПАДА вот такой: 

И даже не переводит сайт на русский язык. Я думаю у вендора тоже нет ответа что не так - он просто смотрит что на западе задачи РАБОТАЮТ и выходит туда с узким решением. 

Александр, почему ЭТО не работает у НАС?! ))

____

Коллеги - это не реклама. Такая же история у ВСЕХ вендоров. Ни у кого задачи не начинают работать "сами по себе".

 

Сергей Бушмелев 29 сентября 2014 г. 23:40  
Но все равно подобные решения не становятся массовыми и продаются скорее за кампанию с прикладными решениями.

У меня есть одно предположение. Не знаю, насколько оно близко или далеко от реальной жизни, тем не менее...

 

1. Механизм задач/заданий в СЭД/ECM/BPM может быть слишком абстрактен и универсален. Чтобы мыслить такими категориями, нужно либо работать в компании-вендоре, производящей СЭД/ECM/BPM, либо испытывать очень сильное влияние последних. Задачи/задания при внедрении СЭД/ECM/BPM в лучшем случае могут быть удобны для некоторых бизнес-процессов, в худшем - неудобны для всех. Причины могут быть самые разные - от банального неудобства системы до незрелости, ненормальности, неорганизованности, неупорядоченности взаимоотношений в организации.

 

2. Для взаимоотношений с коллегами и партнерами обычно используется целый арсенал инструментов. Я сам для решения рабочих (не административных) вопросов использую электронную почту, Скайп, Линк, видеосвязь Policom в самых разных сочетаниях, в каждом случае руководствуясь удобством для всех сторон. Это может быть как общение "тет-а-тет", так и совещания с участниками разных команд. Ну еще живые летучки, совещания никто не отменял. Чем  в хорошем смысле слова неформальнее отношения, чем больше исходящей инициативы и добровольной ответственности, тем меньше нужны средства контроля и принуждения. Нежелание подводить коллег, здоровый культивируемый перфекционизм мотивируют больше, чем жесткий срок в задании. ИМХО.

 

3. В продолжении пункта 1. Решать приходится не абстрактные задачи/задания/поручения, а более приземленные вопросы, поэтому для разных задач существуют свои удобные инструменты. Для инцидентов это может быть Jira, для планирования и отслеживания разработки - YouTrack. А административные задачи типа подачи заявки на командировки удобно решать через корпоративный портал, заполнив интерактивную форму. А как оно там, в части бэк-офиса, "рядовому" разработчику может быть просто неинтересно. Главное, чтобы услуга была оказана оперативно, адекватно, и с минимумом телодвижений. Возможно, СЭД/ECM/BPM  вендоры используют свои продукты внутри компании для решения и административных, и "продуктивных" задач (иначе, думаю, просто невозможно сделать хоть как-то удобный и адекватный продукт), но остальные организации могут запросто пойти на разведение "зоопарка" информационных систем, ориентированных на решение отдельных задач.

 

 

Виктор Золотов 30 сентября 2014 г. 00:39  

Сергей, спасибо!

Уже не в первый раз от тебя проходит мысль, что формальные механизмы (типа задач) снижают уровень личного общения, снижают гибкость, делают самих людей формальными. Что плохо, конечно. Но вот вопрос - Фейсбук действует также, или он наоборот завернул историю на новый цикл общения? О чем я... Раньше люди общались на площадях как сеть, потом газеты/телевизор затолкал их в дома превратив социальную топологию в звезду, а теперь соц. сети снова вытащили людей на площади, но уже виртуальные. Если соц. сети реально улучшают общение, как это прикрутить к задачам (условно)? Ответы тоже есть - Yammer, например, в какой-то мере. Может к задачам Yammer прикрутить? ). Эта идея жива вообще?

Что касается зоопарка систем. А вот если зайти с той стороны, что мне как человеку (ну не лично мне, к сожалению) надо иметь все задачи в одном месте для тайм менеджмента, например. Хочу в матрицу Эйзенхаура  все затолкать, например. Тогда можно считать, что есть потребность в агрегации всех задач из всех систем. Какие минусы в такой схеме?

Сергей Бушмелев 30 сентября 2014 г. 09:57  

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

В творческих средах, например, разработке ПО и сервисов, опять же на мой взгляд, важны поддержка и понимание как внутри команд, так и между ними. Взаимодействие должно быть настроено так, чтобы не возникало необходимости жаловаться "большому дяде" на несговорчивость или противодействие коллег. Да и самих "больших дядей", стоящих над процессом и занимающихся тем, чтобы разруливать конфликты команд, может не быть. Могут быть "моральные лидеры", не обязательно занимающие какие-то высокие посты, которые помогут найти компромисс.  Апеллировать здесь в случае нарушения формальной задачи не к кому, поэтому необходимость в таком механизме, думаю, ниже.  При таком стиле управления и взаимодействия, на мой взгляд, нужны более гибкие, "дискуссионные" механизмы, а информационная система нужна для фиксирования фактов и договоренностей. Не уверен насчет Yammer, для разработки весьма неплох YouTrack. Также возрастает нагрузка на электронную почту, IM, личные или виртуальные совещания. 

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

Александр Сидоренков 30 сентября 2014 г. 14:08  
Почему нет вирусного эффекта, почему люди НЕ начинают слать себе задачки как на картинке?

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

 

 

Александр Сидоренков 30 сентября 2014 г. 14:17  
Механизм задач/заданий в СЭД/ECM/BPM может быть слишком абстрактен и универсален. Чтобы мыслить такими категориями, нужно либо работать в компании-вендоре, производящей СЭД/ECM/BPM, либо испытывать очень сильное влияние последних

В точку!

 

 

Максим Смирнов 30 сентября 2014 г. 21:44  

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

С другой стороны, в прошлом году я участвовал в проекте, в котором изначально были заложен ежедневный контроль статуса исполнения поручений (либо конф-колл либо встреча с отчетом). Через 2-3 недели из толпы неорганизованных начальников мы превратились в идеальных исполнителей поручений. 

Сейчас обсуждают
Евгений Кочуров 20 марта 2017 г. 07:49  
Юрий Зерин 18 марта 2017 г. 19:18  
Сергей Бушмелев 15 марта 2017 г. 22:47  
Елена Истомина 15 марта 2017 г. 13:08  
Сергей Бушмелев 15 марта 2017 г. 10:46  
Больше комментариев