Download to read offline
Uploaded bySergiy Gladkyy
презентация 6 июля 2012
Документ описывает стратегию повышения эффективности внутренних процессов компании, анализируя текущую ситуацию и определяя основные проблемы, такие как отсутствие структурированности и слабая координация. Для достижения поставленных целей предлагаются изменения в методах работы и использование новых инструментов и методологий, включая MBO и платформу social enterprise. Также рассматриваются необходимые ресурсы и сроки для реализации таких изменений через проекты newton и teamlab.
презентация 6 июля 2012
- 1.
- 2. Содержание • Анализ ситуации •Стратегия развития • Методология • Программные системы
- 3. Анализ ситуации Особенности компании
- 4. Анализ ситуации -особенности компании • Быстрый рост и желание так продолжать • Специфика принятия решений • Изменчивость задач и проектов • Нет однородной структуры компании • Коммуникация: почта и телефон + совещания
- 5. Анализ ситуации Сдерживающие факторыи их проявления
- 6. Анализ ситуации -сдерживающие факторы • Руководство не видит всю картину происходящих событий • Задачи верхнего уровня не формализуются • Слабый механизм отрицательной обратной связи • Не развита культура накопления знаний и обмена знаниями
- 7. Анализ ситуации -эффекты • Затруднена своевременная реакция, если что-то пошло не так • Может не хватать информации для принятия решений • Не все проекты завершаются хорошо (сроки бюджеты) • “Разбег” между ожиданиями бизнеса и пониманием задач на местах
- 8. Анализ ситуации -что еще сдерживает • Перетягивание ресурсов • Отсутствие цепочки ответственности • Недостаточно скоординированная работа • Распыление информации вместо консолидации (напр. почта)
- 9. Анализ ситуации Чего хотим добиться
- 10. Анализ ситуации -чего хотим добиться Быстро получать картину происходящего • С заданным уровнем детализации • В реальном времени • На всех уровнях управления
- 11. Анализ ситуации -чего хотим добиться Быстро получать картину происходящего • Видеть понятную сводную информацию • Видеть взаимосвязи между событиями (суть вещей) • Пульс - лента активности • Понимание, что чем занят и для чего
- 12. Анализ ситуации -чего хотим добиться • Своевременно влиять на ход событий • Прогнозировать • Накапливать информационный капитал • При этом, ускориться, а не замедлиться
- 13. Итого • Нужны средствасквозного видения происходящего и поддержки принятия решений • Нужны средства накопления данных и координации • Нужно, чтобы люди были мотивированы, в том числе в использовании новой системы
- 14. Стратегия развития • Измененияв головах у людей • Изменения в методах работы • Новый инструментарий
- 15. Стратегия развития -изменения в головах • Добавление прозрачности • Больше самостоятельности • Ориентация на взаимодействие и обмен опытом • Жизнь в режиме SMART
- 16. Стратегия развития -изменения в методах • Новые методы постановки задач и генерации проектов • Измеряемость процессов • Бизнес-функции
- 17. Стратегия развития -инструментарий • Семантическая основа • Хранилище знаний • Учетная система • Social Enterprise • Средство обмена • Платформа приложений
- 18. Методология • MBO • SocialEnterprise
- 19. Методология - MBO •Постановка целей (бизнес-задач) • Достижение результата • Декомпозиция и каскадирование • Контроль выполнения • Мотивация
- 20. Методология - MBO- Механизмы • Система показателей эффективности • Каскадирование по структуре • Мотивация: SMART-карта MBO • ОВК
- 21. Методология - MBO- Сложности • Сопротивление прозрачности
- 22. Методология - SocialEnteprise • Crowdsourcing (People as Platform) • Communication, Collaboration, Coordination • Knowledge Base
- 23. Инструменты • Хранилище • Аналитика •Интерфейсы (ввод, вывод) • Социальный движок • Платформа ддля приложений • + Скорость + Мультиплатформенность
- 24. Инструменты - Хранилище- Варианты • Репликация на все устройства • Семантический “склад сущностей” • Вики-система • Теневые сущности • Файлы
- 25. Инструменты - Аналитика- Варианты • Поиск взаимосвязей • Нахождение, классификация, упорядочивание • Прогнозирование • Масштабирование • Машина времени
- 26. Инструменты - Учет- Варианты • Crawling • Накопление - итоги - отчеты • Упорядочивание • Структурирование • Сводные данные
- 27. Инструменты - Ввод- Варианты • Единая строка ввода • Гео-привязки • Голосовой ввод
- 28. Инструменты - Вывод- Варианты • Концепция доски • Инфографика • Интерактивные средства
- 29. Инструменты - Социальныефункиции • People as the Platform • Follow everything • Mentions • Messaging & Sharing • Reputation
- 30. Инструменты - Приложения- Примеры • Кабинеты (ведение переговоров) • Управление проектами и задачами
- 31. Инструменты - Интеграция- Примеры • API • Ввод данных “с полей”
- 32. Инструменты - Мультиплатформенность •Browser • Application • Tablet / phone - “книга жизни”
- 33. Инструменты - Реализация •С дальним прицелом - Newton • С ближним прицелом - TeamLab
- 34. Реализация - Newton* • Фиксация начальной бизнес-задачи • Структурирование бизнес-проблемы • Генерация идей, контр-идей • Проектная композиция (SMART) • Эффективное выполнение • Анализ состояния *Методология описана отдельным документом
- 35. Newton - оценка Разработка пилотной версии • Проектирование хранилища • Аналитическая система • Интерфейсы ввода-вывода - 3 DB Architects - 3 Software Developers - 3 Web Developers - 1 System Design Architect - 1 Project Manager - 1 UI/UX Designer И по срокам - 6 месяцев активной работы
- 36. Реализация - TeamLab Ужеесть: • Управление задачами и проектами • Некоторые коммуникационные возможности (обсуждения) • Может взять на себя часть роли "Хранилище данных". Не всю • Зачатки отчетного механзма. Можно будет делать некоторую аналитику, выдаваемую в таблицы
- 37. Реализация - TeamLab Надодобавить: • Dashboard + widgets • Dashboard backend • UI / UX
- 38. TeamLab - оценкапилота - 1 DB Architect - 2 Web Developers (Dashboard + widgets) - 1 System Design Architect (можно совместить с PM) - 1 Project Manager - 1 UI/UX Designer (привлеченный, сдельно) По срокам - приблизительно 3 месяца работы в такой команде
Editor's Notes
- #2 \n
- #3 \n
- #4 \n
- #5 Не хотим зацементироваться\nКарт-бланш\n
- #6 \n
- #7 Не видно: влияние мелких задач на главные цели, взаимосвязь между различными проектами\n
- #8 \n
- #9 Нет механизма планирования нагрузки на ресурсы (пул которых, по большому счету, общий)\n\nЧасто отделы не до конца довольны работой друг друга в силу неполного понимания взаимных обя\n\n
- #10 \n
- #11 \n
- #12 \n
- #13 \n
- #14 На всех уровнях, не только топы\n
- #15 Чтобы что-то взять, надо что-то положить\n\n\nТребуемая прозрачность и управляемость может быть достигнута сочетанием мер\n    ▪    Организационно-методологических - классические методики\n    ▪    Социализация предприятия\n    ▪    направление энергии \n    ▪    Инструментальных (костылей)\n    ▪    Одними инструментами тут не обойтись. Однако, кое-чего можно добиться тоже.\n\nОчевидно, что технические средства в чистом виде проблему не решат, что ни проектируй. Для того, чтобы получить какую-то информацию, нужно ввести достаточное количество исходных данных. Нужна процедура, которая бы обеспечивала это, с учетом того, что любой ввод, это рутина, которая отнимает время. \n\n
- #16 \n
- #17 \n
- #18 Инструмент для управления уникальной компанией нужен тоже уникальный. Такой, какого нет пока ни у кого: \n- Все запоминаем\n- В фоне анализируем\n- Помогаем принимать решения\n- Способствуем коммуникации и накоплению данных\n\n
- #19 В рамках данной презентации не будем очень подробно останавливаться на методологии, поскольку тема большая настолько, что достойна отдельного выступления. Скажу кратко. Идейный костяк составляют следующие вещи \n
- #20 Это процесс согласования целей внутри организации, таким образом, что руководство компании и сотрудники разделяют цели и понимают, что они означают для организации.\nДостижение того, чтобы цели были ясны с самого начала (с верху) и до нижних уровней исполнения - это залог успеха \nПеречислим важные методологические моменты, на которые мы будем опираться\n1) Ставятся цели. Цель (Задача) - конкретно сформулированное желание руководства компании достичь определенного результата. От них и пляшем. Может существовать вспомогательный механизм "конкретизации" - например коллективный мозговой штурм. В рамках нашей системы мы можем рассматривать цель в более узком смысле нежели канонический. Это может быть какая-то довольно высокоуровневая задача, требующая вовлечения ресурсов разных подразделений\n2) Достижение цели возможно только коллективно - совместным трудом сотрудников. Однако, у каждого из них в этом случае будет какая-то своя цель. Соответственно, важны следующие три механизма\n2.1) Декомпозиция высокоуровневых задач в более мелкие с сохранением взаимосвязи. Назначение ответственных за их выполение\n2.2) Контроль за качеством выполнения поставленных задач и сравнение фактических данных с плановыми (идеальными с точки зрения достижения результата)\n
- #21 2.3) Создание условий, когда сотрудники будут сами хотеть выполнять работу максимально хорошо \nДля этого МБО предусматривает следующие механизмы\nСистема показателей эффективности\nКаскадирование их по структруе предприятия\nДальнейшее каскадирование показателей по должностям и сотрудникам\nМеханизм мотивации сотрудника (деление оклада и смарт-задачи). Это соответствует делению деятельности сотрудника на рутину (покрывается окладом) и направленную на достижение конкретных целей\nМеханизм Информационных Потоков. Для конкретной должности бизнес-процессы проявляются в виде информационных потоков,проходящих через нее. \nМеханизм "внутреннего клиента" - отслеживания взаимодействий между должностями внутри организации и оценка внутреннего клиента\nВ итоге, мы получаем такую схему работы, при которой задача грамотно разложена на компоненты, сотрудники понимают, что им надо делать (они сами себе формулируют задачи), бизнес может видеть отклонения от плана\n
- #22 \nВ чем тут сложность. Для того, чтобы "тема пошла", придется повысить прозрачность: нарисовать матрицу клиентоориентированности и указать основные информационные потоки. На практике это означает, что руководители разных рангов должны будут "публично заявить" - описать, чем они занимаются, с кем взаимодействуют. Это может встретить сопротивление\n
- #23 Это тренд на ближайшие лет 5\n\nВторым аспектом является понимание того, что предприятие, это большая социальная система (бизнес-социум) и, стало быть, многие технологии социальных сетей могли бы здесь прижиться . Социальные сети, как показывает практика, являются серьезным коммуникационным укорителем , за счет чего можно компенсировать некоторое замедление, неизбежное при вводе регламентов\nОсновные идеи, которые могут быть воплощены и принести пользу\nCrowdsourcing - совместная работа над решением проблемы (People as The Platform)\nCommunication, Collaboration, Coordination - современные методы обмена информацией и совместной работы\nKnowledge Base - "облако знаний"\n\nИ еще\nСемантическая природа системы. Мы можем связывать любые информационные блоки, если эта связь имеет хоть какой-то смысл\n\n\n\n
- #24 Вернемся к начальной задаче. Мы строим систему, которая бы\n\nДавала необходимую информацию, конкретно отвечая на вопросы "как идут дела по такому-то направлению", "какие есть проблемы", "каковы показатели по такому-то проекту" и т.д.\nНе служила бы тормозом процессов развития предприятия\n\nКакими базовыми свойствами должна обладать такая система, чтобы она могла работать:\n\n1) В ней должно быть достаточно информации для этого. \n\nТо есть, разнообразная информация должна туда непрерывно поступать в живом предприятии . Причем, должен быть полный спектр информации, достаточной для анализа, как то: все уровни поставленных задач (от стратегии до отделов и людей в отделах)\n\nПодобная непрерывность и полнота возможно только в одном случае:\n\nСистема является неотъемлемой частью повседневной жизни предприятия. Необходимым инструментом \n\nЧтобы этого добиться, потребуется наделить ее многими качествами, о которых ниже\n\n2) Должен быть аналитический механизм, который в состоянии эту информацию искать, интерпретировать\n\n\n3) Должны существовать мощные средства представления данных\n\n\nИтак, нужный нам инструмент сотрудничества, с учетом всего сказанного выше, выглядит так:\n\nОблачная система уровня предприятия, обладающая функциями\n\nХранилище\n\nЕдиное хранилище данных (включая файлы). Данные доступны пользователю на всех его устройствах\nБазы знаний - семантическое связывание любых информационных блоков\nУмеющая получать данные из внешних источников и отдавать их наружу\nОбладающя интерфейсами обмена информацией (сообщения, файлы). При том, что информация должна, по возможности, не покидать хранилище и не дублироваться\n\nАналитика\nОбладающая аналитическим механизмом, помощающ\nИмеющая при этом учетный механизм\n\nВвод\nИмеющая интерфейсы ввода информации, удобные для своих целевых групп\n удобные\n понятные\n максимально полные\n интеллектуальный интерфейс "разговора" с системой\nВывод\nОбладающая мощным изобразительным механизмом (опирается на хранилище и аналитику)\n форматированный вывод\n отчеты\n Инфографика\n\nСоциальный движок\nСнабженная "механизмом сотрудничества" - социальные функции\n\nПриложения\nВозможность пользоваться опорными механизмами, указанными выше для разработки прикладных решений (решения конкретных задач). Таких, как управление проектами\n\nКроме того\n\nРаботающая "без тормозов", "со скоростью гугла" \nПоддерживающая разные пользовательские платформы\n
- #25 1) по аналогии с iCloud Все хранится в облаке, часть (нужная) кешируется локально на любое из подключенных устройств\n2) То есть, единицей хранения является любой смысловой элемент\n- задача\n- проект\n- файл\n- мысль\n- статья \n\nи так далее\n\n3) как часть базы знаний\n4) \nКонцепция предполагает, что некоторые данные могут существовать толко в своей "натуральной среде" и не быть легко отчуждаемыми. К примеру - документ 1С. В то же время, их нужно хранить в общем хранилище и подвергать анализу. Поэтому, в хранилище создается "представление" сущности с сохранением связи с оринигалом. Представление может выглядеть как скрин шот или как копия\n5) Частный случай "сущности"\n\n
- #26 Прогнозирование: what-if\n
- #27 \n
- #28 1) По аналогии с Гугл. Возможно, с поддержкой тегов. Смысл: мы просто говорим системе, что мы хотим туда ввести или получить.\nХорошего прогресса добился Гугл в Г+ с интерпретацией вставляемых данных, поддержкой аттачментов\n\n
- #29 Взято из SCRUM. На доске располагаем карточки сущностей (например - задач)\nДвигаем по разным зонам, фиксируя прогресс\n\nПри подержке хранилища и аналитического движка, представляется возможным автоматически строить как тривиальные диаграммы, так и достаточно необычные вещи\n\n
- #30 Лента - Это пульс предприятия. Все то, на что люди подписались (зафолловили) и другая важная информация - отображается в нейВажно не допустить замусоривания, когда пульс превратится в шум\nFollow everything\nДолжна быть возможность "зафолловить" (и наоборот) буквально все\nЧеловека\nДокумент\nСобытие\nВопрос\nТему\nИ так далее. Люди сами решают, что им нужно\n\n
- #31 \n
- #32 API - Часть данных (довольно большая) будет вливаться из внешних систем. Например, учетных или же можно снимать данные с механических агрегатов и \nТехнологии типа Speech API для распознавания и синтеза речи\n\nНаша задача - как больше “кирпичиков” положить в систему\n
- #33 \n
- #34 \n
- #35 Проект Newton является прикладным решением на базе описанной платформы. Оно опирается на большинство изложенных выше идей и решает задачу построения системы управления задачами и проектами\n\n\nФункционал\n\nФиксация самой начальной потребности (бизнес-задачи)\nСтруктурирование причин появления, поиск ключевых проблем \nГенерация идей, их защита и компоновка проектов/работ\nПланирование задач и ресурсов на уроне отделов\nОрганизация эффективного исполнения задач\nМетоды анализа состояния\n\nКратко суть идеи можно описать следующим образом\n\n1) Менеджмент формулирует задачу на совещании (или в электронном виде). Задача формулируется группе "экспертов" из числа компетентных в вопросе руководителей, включая тех, кто предполагается быть вовлеченным в исполнение. Здесь идет речь о таких вопросах, которые выходят за рамки банальных\n\n2) Эксперты "структурируют неопределенности" - строят "рыбу" или root-cause diagram - дерево первопричин, которые привели к возникновению задачи или проблемной ситуации. Это будут потенциальные кандидаты на проекты или крупные задачи к выполнению\n\n3) Эксперты последовательно перебирают найденные на предыдущем шаге проблемы и методом "мозгового штурма" пытаются найт адекватные решения. То есть, каждая из них может обсуждаться (выноситься суждения) и за каждое суждение можно подавать голос\n\nСистема на этих этапах помогает визуально структурировать Задачи-Причины-Решения, а также дает возможность их обсуждать\n\n4) Когда задача "разложена" и для каждой составляющей найдено адекватное решение, мы видим перед собой потенциальный проект или несколько проектов, но их надо правильно сформировать (в формате SMART), а именно:\n\n- Выделить цели \n- Прописать критерии завершенности (приемки результата)\n- Предложит реализацию\n- Рассчитать бюджет\n- Рассчитать дедлайн\n- Сформировать команду\n\nДля этого объявляется проектный тендер и участники (как правило, из числа экспертов) предлагают свои варианты. Выигравший тендер получает "мандат" на проект - необходимый ресурс. Остальные участники тендера, скорее всего, будут тоже вовлечены на каких-то этапах, предоставляя ресурсы из своего пула (они - руководители). При этом, не придется вводить их в курс дела. Они уже в курсе\n\n5) Уже на этапе 4 происходит ресурсное планирование и резервирование\n\n6) На уровне отделов создается система, связанная с описанной выше, но ориентированная на выполнение задач сотрудниками.\n\n7) Частью этой системы служит разработанная схема мотивации для сотрудников, при которой им будет интересно разбирать задачи и выполнять их в кратчайшие сроки\n\n8) Сотрудники отделов выполняют и закрывают поставленные задачи\n\n9) Система протоколирует действия и обновляет статус выполнения бизнес-задачи\n\n\nКакие главные компоненты платформы нужны для реализации методологии\n\nХранилище \n\n- склад сущностей. Проекты, задачи и их свойства, люди - все лежит внутри в виде своеобразной паутины\n\nАналитика\n\n- учетная система. Здесь по большей части понадобятся стандартные "регистры" для индексирования и связывания данных с возможностью быстрых отборов\n\nВвод\n\n- Понадобится разработка механизмов, описанных в методологии: древовидные структуры, дискуссии, электронные формы документов\n\nВывод\n\n- Концепция доски\n- Карта взаимосвязей\n- Отчеты\n- Дискуссии\n\nКроме того, в процессе исполнения может полностью задействоваться социальный компонент. Но это опция\n\n
- #36 Реализация проекта должна проходить следующими этапами\n\n1) Проектирование семантического хранилища\n2) Проектирование учетной подсистемы\n3) Проектирование ввода-вывода \n\n\nКроме того, параллельно этому должна проводиться работа по внедрению основных принципов, описынных в разделе методология. Главным образмом: мотивационные схемы, повышение понятности выполняемых функций и некоторая их систематизация\n\nОценки здесь могут быть даны весьма приблизительно. Для более точного планирования необходима детальная проработка\n\n\nПроектирование хранилища\n\nЗадача может показаться достаточно сложной (каковой, в общем-то, и является проектирование DWH). Однако, не обязательно делать сразу все. Вполне можно изготовить упрощенную версию малыми силами (без балансировки нагрузки, репликации, оптимизации производительности и тп). Сама суть идеи реализуется достаточно просто\n\nРазработка полноразмерного хранилища подобной структуры представляется возможной силами трех человек за период примерно полгода\n\nРазработка упрощенной версии семантического ядра может быть выполнена одним опытным DB Architect в течение месяца.\n\nАналитическая система\n\nПрежде всего, мы говорим об учетной системе, которая располагается "вокруг" ядра. Она черпает оттуда информацию и фиксирует в своих "регистрах". Проиндексированные данные готовы для создания отчетов или использования в принятии решений\n\nОсобенностью является то, что учетная система, это некий "кэш" того, что находится в ядре. Новая информация поступает в ядро и поэтому потребуется взаимодействие, чтобы расчеты были актуальными\n\nРазработка подобной учетной системы может занять порядка полугода силами команды из трех человек, если делать это "с нуля", силами опытного разработчика. Хорошей новостью является то, что у нас имеются наработки на эту тему, которые можно будет исползовать в проекте. В этом случае, можно говорить о двух-трех месяцах адаптации силами одного разработчика (при совпадении языковой платформы). \n\nЕще можно использовать внешние учетные системы для этого, типа 1С\n\nТогда для доработки понадобится один 1С программист и базовые работы можно завершить в течение месяца\n\nИнтерфейсы ввода-выода\n\nЗдесь и будет основная нагрузка на разработку. Придется серьезно заниматься нестандартной и стандартной визуализацией\n\nЗдесь понадобится 3 веб разработчика (на выбранной платформе) и приблизительно полгода работы\n\nИтого, мы видим, что для изготовления первого рабочего прототипа программной системы Newton требуется\n\n- 3 DB Architects\n- 3 Software Developers\n- 3 Web Developers\n- 1 System Design Architect\n- 1 Project Manager\n- 1 UI/UX Designer\n\nИ по срокам - 6 месяцев активной работы\n
- #37 Учитывая, что развития компании происходит очень активно и какие-то шаги нужно принимать прямо сейчас (а не ждать полгода), можно воспользоваться какой-то готовой, наиболее подходящей под задачи системой, доведя ее до приемлемого состояния "малыми силами"\n\nНаша главная задача состоит в предоставлении связного видения происходящих процессов и связанных с ними работ (задач, проектов). Соответственно, подойдет система, обладающая свойствами:\n\n1) Позволяет управлять задачами и проектами\n2) Может быть развернута внутри компании\n3) Имеет возможность развития: API, Open Source\n\nОдной из наиболее подходящих является TeamLab, который удовлетворяет всем трем критериям. \n\nПеречислим подходящие для наших нужд свойсва системы\n\n1) Управление задачами и проектами\n2) Некоторые коммуникационные возможности (обсуждения)\n3) Может взять на себя часть роли "Хранилище данных". Не всю\n4) Зачатки отчетного механзма. Можно будет делать некоторую аналитику, выдаваемую в таблицы\n\n
- #38 Кратко охарактеризуем моменты, которые требуют внимания и возможной доработки\n\n1) Отсутствует межпроектная аналитика. Это не даст возможность строить диаграммы взаимосвязи проектов. Это надо делать\n2) Отсутствие изобразительных механизмов, описанных в методике. Эти же взаимосвязи надо визуализировать и это надо будет делать\n3) Переусложненный интерфейс ввода данных. Подойдет для Айти-отделов, но неприемлемо "наворочен" для остальных. Не позволяет вводить информацию быстро (а это важно).\n\nРассмотрим случай внедрения системы в отделе ВАМ\n\nВ этом случае с п.3 можно стартовать, оставив его как есть. Потребуется добавление следующих функций\n\n1) Dashboard + widgets - сводные данные, визуализация\n2) Dashboard backend - вторая часть Хранилища, которая будет опираться на базу TeamLab, но содержать дополнительную информацию, специфичную для дашборда\n\n3) Переработка интерфейсов ввода. Это можно стартовать вторым этапом, пока не оцениваем\n\n\n
- #39 1) Dashboard + widgets - сводные данные, визуализация\n2) Dashboard backend - вторая часть Хранилища, которая будет опираться на базу TeamLab, но содержать дополнительную информацию, специфичную для дашборда\n\n3) Переработка интерфейсов ввода. Это можно стартовать вторым этапом, пока не оцениваем\n\nУчтем, что система написана на .net\n\nРазработка п.1 и п.2 должна вестись параллельно, силами разных людей плюс привлеченный дизайнер\n\n- 1 DB Architect\n- 2 Web Developers (Dashboard + widgets) (можно взять одного, но вытянутся сроки в полтора раза)\n- 1 System Design Architect (можно совместить с PM)\n- 1 Project Manager\n- 1 UI/UX Designer (привлеченный, сдельно)\n\nПо срокам - приблизительно 3 месяца работы в такой команде\n