Героизм руководителя проекта
В мире 1С руководитель проекта часто пытается выполнять сам несколько ролей или волею случая становится многостаночником.
Эта порочная практика имеет много Корней, и самый главный из этих Корней - в мире 1С руководителями проектов становятся вчерашние внедренцы. При этом они и раньше зачастую сочетали в себе и консультантов, и разработчиков, и методологов - и всех тех, кто нужен был в проектах, но бюджета на них не было.
С другой стороны, у руководителя проекта часто «чешутся руки» показать команде как и что делать правильно.
Избегайте этого.
Используйте аутотренинг: Рефлексируйте каждый вечер, отвечая себе на вопрос «Где я сегодня пытался что-то сделать?» и «Как мне научить команду делать так, как я хочу?»
Пробуйте разные подходы на следующий день: если позволяет время, рецензируйте и возвращайте на доработку, проводите индивидуальные беседы и семинары, моделируйте встречи. Делайте все так, как будто вы не знаете, что нужно делать
В мире 1С руководитель проекта часто пытается выполнять сам несколько ролей или волею случая становится многостаночником.
Эта порочная практика имеет много Корней, и самый главный из этих Корней - в мире 1С руководителями проектов становятся вчерашние внедренцы. При этом они и раньше зачастую сочетали в себе и консультантов, и разработчиков, и методологов - и всех тех, кто нужен был в проектах, но бюджета на них не было.
С другой стороны, у руководителя проекта часто «чешутся руки» показать команде как и что делать правильно.
Избегайте этого.
Используйте аутотренинг: Рефлексируйте каждый вечер, отвечая себе на вопрос «Где я сегодня пытался что-то сделать?» и «Как мне научить команду делать так, как я хочу?»
Пробуйте разные подходы на следующий день: если позволяет время, рецензируйте и возвращайте на доработку, проводите индивидуальные беседы и семинары, моделируйте встречи. Делайте все так, как будто вы не знаете, что нужно делать
План управления проектами - вот он, на полке лежит
Примерно такую фразу слышишь каждый раз, когда задаешь вопрос руководителю проекта. А во многих случаях делаются удивленные глаза и руководитель проекта задает вопрос: "А что это?"
На самом деле все руководители проектов строят так или иначе план управления проектом (ПУП). Кто-то делает это неформально, кто-то более формально, кто-то включает положения ПУП в Устав проекта. Почему так происходит?
1. Не все знакомы с теорией PMI о том, что план управления проектом - отдельный документ. Этот факт таков потому, что ПУП является "живым" документом, то есть он может меняться в ходе выполнения работ. Вы можете передоговариваться о каналах коммуникации, способах управления рисками, добавлять или убирать контрольные события - от этого не изменяются ключевые параметры проекта.
2. Многие живут в парадигме неформального заключения ПУП - на словах. Это бывает полезно, когда вы делаете небольшой проект, а процесс разработки ПУП занимает больше 40 часов руководителя проекта с учетом цикла выработки решений, согласований и прочих особенностей документооборота всех участвующих в проекте сторон. Тогда руководитель проекта должен осознавать, что источник плана управления проектом для него - юридический договор. Именно там содержатся процедуры и положения проекта, которые пожелали включить туда на этапе составления
3. В проектах часто приходится видеть, как положения ПУП включают в Устав проекта. Методологически это не совсем верно, но в каком -то смысле это частный случай п.2 - настоящим Уставом проекта для вас становится юридический договор, а то, что называется в проекте Уставом является по сути ПУПом. Полезно ли это? Конечно, полезно, если вы руководствуетесь положениями ПУП и они не противоречат договору
И вот тут-то и кроется особенность ПУП как документа управления проектом. Эта же особенность относится, к сожалению, к договорам.
Эти документы быстро устаревают, жизнь вносит изменения в проект, а вот документы обновлять забывают.
В случае с ПУП, поскольку он является сугубо управленческим документом, и служит для улучшения коммуникации сторон, документ быстро деградирует до состояния неактуального, когда его обновление сулит полную переделку. Представьте себе, что кто-то потратил на этот документ неделю своего времени, а то и не одну.
Отклонения от договора вовсе является порочной практикой и ни к чему хорошему не ведет.
Если вы и ваша команда издали документ, пожалуйста, следите за тем, чтобы он применялся по назначению и актуализировался своевременно.
Примерно такую фразу слышишь каждый раз, когда задаешь вопрос руководителю проекта. А во многих случаях делаются удивленные глаза и руководитель проекта задает вопрос: "А что это?"
На самом деле все руководители проектов строят так или иначе план управления проектом (ПУП). Кто-то делает это неформально, кто-то более формально, кто-то включает положения ПУП в Устав проекта. Почему так происходит?
1. Не все знакомы с теорией PMI о том, что план управления проектом - отдельный документ. Этот факт таков потому, что ПУП является "живым" документом, то есть он может меняться в ходе выполнения работ. Вы можете передоговариваться о каналах коммуникации, способах управления рисками, добавлять или убирать контрольные события - от этого не изменяются ключевые параметры проекта.
2. Многие живут в парадигме неформального заключения ПУП - на словах. Это бывает полезно, когда вы делаете небольшой проект, а процесс разработки ПУП занимает больше 40 часов руководителя проекта с учетом цикла выработки решений, согласований и прочих особенностей документооборота всех участвующих в проекте сторон. Тогда руководитель проекта должен осознавать, что источник плана управления проектом для него - юридический договор. Именно там содержатся процедуры и положения проекта, которые пожелали включить туда на этапе составления
3. В проектах часто приходится видеть, как положения ПУП включают в Устав проекта. Методологически это не совсем верно, но в каком -то смысле это частный случай п.2 - настоящим Уставом проекта для вас становится юридический договор, а то, что называется в проекте Уставом является по сути ПУПом. Полезно ли это? Конечно, полезно, если вы руководствуетесь положениями ПУП и они не противоречат договору
И вот тут-то и кроется особенность ПУП как документа управления проектом. Эта же особенность относится, к сожалению, к договорам.
Эти документы быстро устаревают, жизнь вносит изменения в проект, а вот документы обновлять забывают.
В случае с ПУП, поскольку он является сугубо управленческим документом, и служит для улучшения коммуникации сторон, документ быстро деградирует до состояния неактуального, когда его обновление сулит полную переделку. Представьте себе, что кто-то потратил на этот документ неделю своего времени, а то и не одну.
Отклонения от договора вовсе является порочной практикой и ни к чему хорошему не ведет.
Если вы и ваша команда издали документ, пожалуйста, следите за тем, чтобы он применялся по назначению и актуализировался своевременно.
Что такое продажа проектов и с чем ее едят
По роду своей деятельности мне приходится сталкиваться с продажами проектов на 1С. В нашем мире часто под продажами понимают заключение договора, причем сделать это необходимо любой ценой. В ход идет все - обман, недосказанность, подлог, связи и все остальное, что есть на вооружении "истинных продавцов". К сожалению, редко в этом перечне встречаются содержательные критерии.
А ведь что такое продажа? Это достижение взаимовыгодного баланса для двух сторон, который был бы одинаково полезен и продавцу, и покупателю. На чашу весов кладутся
- имидж компаний и бренды
- гудвилл
- прибыль и расходы
- ресурсные возможности и потребности
- деньги и качество
- опыт и освоение новых рынков
Когда баланс указанных выше аспектов достигается сторонами, получается равновесие в чаше сотрудничества. И тогда проект рискует быть успешным. Но так бывает не всегда. Когда в дело вступают настоящие продавцы, которые не отвечают за исполнение проекта, или больше мотивированы на продажи, остается только один аргумент - сделка любой ценой. И вот тут кроется источник многих проблем.
Продавая проекты, важно балансировать аспекты обеих сторон и понимать обе стороны. При дисбалансе в любую сторону появляется давление, появляется потребительское отношение с наиболее сильной стороны. И это не всегда покупатель. Понимая свою силу, сторона начинает требовать, давить, шантажировать и пытаться взять от ситуации максимум. Никогда такая модель поведения на моей практике ни к чему хорошему не приводила. Например, в корпоративном рынке часто встречается, что клиент пользуется очень большой стоимостью бренда, которую сложно перебить чем-то еще.
Важно использовать для взвешивания только те аспекты, которые важны компаниям. Потому что часто на решения влияют личные амбиции - карьерные или зарплатные ожидания, демотивация исполнителей, личная неприязнь и другие особенности конкретных людей. Безусловно, если между командами на этапе продажи возникает конфликт и недопонимание, то это будет являться ограничением в продаже. Но при анализе баланса выгод стоит брать в расчет только аргументы компаний.
Поэтому важно при продаже тщательно и выверенно предлагать услуги, которые вы можете оказать. При этом складывая на чашу весов все, что есть у вас и что есть у другой стороны. Не стоит вступать в некачественные сделки ради краткосрочной выгоды заключения договора. Лучше упустить сделку, в которой вы видите, что не получится договориться, и взять следующую.
Особенно это важно в условиях текущего рынка, испытывающего колоссальный дефицит квалифицированных команд, способных делать качественные проекты внедрения 1С.
По роду своей деятельности мне приходится сталкиваться с продажами проектов на 1С. В нашем мире часто под продажами понимают заключение договора, причем сделать это необходимо любой ценой. В ход идет все - обман, недосказанность, подлог, связи и все остальное, что есть на вооружении "истинных продавцов". К сожалению, редко в этом перечне встречаются содержательные критерии.
А ведь что такое продажа? Это достижение взаимовыгодного баланса для двух сторон, который был бы одинаково полезен и продавцу, и покупателю. На чашу весов кладутся
- имидж компаний и бренды
- гудвилл
- прибыль и расходы
- ресурсные возможности и потребности
- деньги и качество
- опыт и освоение новых рынков
Когда баланс указанных выше аспектов достигается сторонами, получается равновесие в чаше сотрудничества. И тогда проект рискует быть успешным. Но так бывает не всегда. Когда в дело вступают настоящие продавцы, которые не отвечают за исполнение проекта, или больше мотивированы на продажи, остается только один аргумент - сделка любой ценой. И вот тут кроется источник многих проблем.
Продавая проекты, важно балансировать аспекты обеих сторон и понимать обе стороны. При дисбалансе в любую сторону появляется давление, появляется потребительское отношение с наиболее сильной стороны. И это не всегда покупатель. Понимая свою силу, сторона начинает требовать, давить, шантажировать и пытаться взять от ситуации максимум. Никогда такая модель поведения на моей практике ни к чему хорошему не приводила. Например, в корпоративном рынке часто встречается, что клиент пользуется очень большой стоимостью бренда, которую сложно перебить чем-то еще.
Важно использовать для взвешивания только те аспекты, которые важны компаниям. Потому что часто на решения влияют личные амбиции - карьерные или зарплатные ожидания, демотивация исполнителей, личная неприязнь и другие особенности конкретных людей. Безусловно, если между командами на этапе продажи возникает конфликт и недопонимание, то это будет являться ограничением в продаже. Но при анализе баланса выгод стоит брать в расчет только аргументы компаний.
Поэтому важно при продаже тщательно и выверенно предлагать услуги, которые вы можете оказать. При этом складывая на чашу весов все, что есть у вас и что есть у другой стороны. Не стоит вступать в некачественные сделки ради краткосрочной выгоды заключения договора. Лучше упустить сделку, в которой вы видите, что не получится договориться, и взять следующую.
Особенно это важно в условиях текущего рынка, испытывающего колоссальный дефицит квалифицированных команд, способных делать качественные проекты внедрения 1С.
Время гибких
Итоги семинара ERP в Ареале показали единодушие многих сторон в вопросе гибкого подхода к внедрению систем на платформе 1С. С учетом кризиса миграции на новые системы, ограничений со стороны законодательства и западных поставщиков многие готовы двигаться быстрыми короткими шажками в сторону платформы 1С.
И это уже совсем другая картина мира.
- Предлагайте клиентам гибкие Agile- и Scrum-подходы, если видите срочность внедрения
- Делите работы на потоки с отдельными владельцами процессов (Scrum of Scrum)
- Часто актируйтесь
- Часто передавайте результаты, пусть и промежуточные
- Не забывайте документировать
Настало время гибких
Итоги семинара ERP в Ареале показали единодушие многих сторон в вопросе гибкого подхода к внедрению систем на платформе 1С. С учетом кризиса миграции на новые системы, ограничений со стороны законодательства и западных поставщиков многие готовы двигаться быстрыми короткими шажками в сторону платформы 1С.
И это уже совсем другая картина мира.
- Предлагайте клиентам гибкие Agile- и Scrum-подходы, если видите срочность внедрения
- Делите работы на потоки с отдельными владельцами процессов (Scrum of Scrum)
- Часто актируйтесь
- Часто передавайте результаты, пусть и промежуточные
- Не забывайте документировать
Настало время гибких
Разность миров
Растет количество компаний, которые мигрируют с SAP или других западных систем. Что важно знать руководителю проекта:
- терминологический аппарат довольно разный, в среде «саперов» приняты англицизмы и термины управления в SAP
- управление в среде SAP - это исключительно политика: как разделить ответственность, как получить нужное решение от конкретной группы людей, как обойти острые углы
- серьезная сегментация специалистов по модулям, вплоть до мелких функций, порождает большое количество людей в проекте
- никто не знает как в целом работает система, каждый знает свой участок
- технологически ИТ всегда защищает SAP, защищает свои решения, и не стоит вступать синими в споры: считают они что 1С плохая система, пусть считают - жизнь покажет
- закладывайте сильных экспертов, формируйте рабочие группы зеркально - если есть у заказчика специалисты по FI-AA, дайте им отдельного специалиста эксперта по ОС
- заказчики в среде SAP уже подготовлены «мировым брендом», что хорошо не будет, играйте на этом
- как правило, центр компетенции и технологии выделены достаточно хорошо, нужно давать людям технологии на 1С: СППР, Vanessa, КИП, Мониторинг
- закладывайте работы по методологии обязательно: наши системы очень разные, концепция учёта разная - требуется детальная адаптация и внедрение в сознание пользователей, как будет на новой системе; если есть в команде методологи - отлично, если нет - найдите консалтингового партнера
- как правило, у компаний есть аудиторы: обратитесь к ним, у клиента обычно с ними высокий уровень доверия
- у SAP есть на уровне платформы инструменты информационной безопасности: и шифрование, и идентификация кибератак, и журналы ИБ и другие инструменты; закладывайте работы по ИБ обязательно - особенно с учетом современных реалий
Не бойтесь менять SAP на 1С. 1С во многом лучше этой платформы, хоть и есть сценарии, в которых функционала или технических возможностей не хватает.
Растет количество компаний, которые мигрируют с SAP или других западных систем. Что важно знать руководителю проекта:
- терминологический аппарат довольно разный, в среде «саперов» приняты англицизмы и термины управления в SAP
- управление в среде SAP - это исключительно политика: как разделить ответственность, как получить нужное решение от конкретной группы людей, как обойти острые углы
- серьезная сегментация специалистов по модулям, вплоть до мелких функций, порождает большое количество людей в проекте
- никто не знает как в целом работает система, каждый знает свой участок
- технологически ИТ всегда защищает SAP, защищает свои решения, и не стоит вступать синими в споры: считают они что 1С плохая система, пусть считают - жизнь покажет
- закладывайте сильных экспертов, формируйте рабочие группы зеркально - если есть у заказчика специалисты по FI-AA, дайте им отдельного специалиста эксперта по ОС
- заказчики в среде SAP уже подготовлены «мировым брендом», что хорошо не будет, играйте на этом
- как правило, центр компетенции и технологии выделены достаточно хорошо, нужно давать людям технологии на 1С: СППР, Vanessa, КИП, Мониторинг
- закладывайте работы по методологии обязательно: наши системы очень разные, концепция учёта разная - требуется детальная адаптация и внедрение в сознание пользователей, как будет на новой системе; если есть в команде методологи - отлично, если нет - найдите консалтингового партнера
- как правило, у компаний есть аудиторы: обратитесь к ним, у клиента обычно с ними высокий уровень доверия
- у SAP есть на уровне платформы инструменты информационной безопасности: и шифрование, и идентификация кибератак, и журналы ИБ и другие инструменты; закладывайте работы по ИБ обязательно - особенно с учетом современных реалий
Не бойтесь менять SAP на 1С. 1С во многом лучше этой платформы, хоть и есть сценарии, в которых функционала или технических возможностей не хватает.
Работы много, а РП - мало или семеро одного не ждут
При большом объеме команды в проекте возникает много особенностей
- Один РП как правило способен качественно управлять 7-14 человеками, иногда до 20, если у него есть таланты
- Команда потребляет большой объем денег каждый час (100 часов каждый час, если в команде 100 человек), невовремя принятое управленческое решение начинает стоить очень дорого
- Дополнительные усилия по балансировке приводят к увеличению работы руководителя проекта
- Обнаружение и реагирование на риски существенно усложняется, команды пытаются перейти на математические формы их идентификации что снижает в целом эффективность работы с ними
Практика показала, что единственный адекватный вариант - разделение на несколько проектных команд. Да, это увеличивает стоимость управления и бюрократизирует работу. И нет, руководители фунциональных групп и прочие полумеры не помогают в этой ситуации, так как эти люди все-таки не только и не столько менеджеры. При такой модели повышается прозрачность, качество планирования, работа с рисками и загрузкой персонала.
При большом объеме команды в проекте возникает много особенностей
- Один РП как правило способен качественно управлять 7-14 человеками, иногда до 20, если у него есть таланты
- Команда потребляет большой объем денег каждый час (100 часов каждый час, если в команде 100 человек), невовремя принятое управленческое решение начинает стоить очень дорого
- Дополнительные усилия по балансировке приводят к увеличению работы руководителя проекта
- Обнаружение и реагирование на риски существенно усложняется, команды пытаются перейти на математические формы их идентификации что снижает в целом эффективность работы с ними
Практика показала, что единственный адекватный вариант - разделение на несколько проектных команд. Да, это увеличивает стоимость управления и бюрократизирует работу. И нет, руководители фунциональных групп и прочие полумеры не помогают в этой ситуации, так как эти люди все-таки не только и не столько менеджеры. При такой модели повышается прозрачность, качество планирования, работа с рисками и загрузкой персонала.
На чьей стороне руководитель проекта?
В каждом проекте есть очень большое количество заинтересованных сторон. Их интересы тесно переплетаются, а порой откровенно противоречат друг другу. Чью сторону выбрать?
Когда мне задают такой вопрос, я отвечаю просто: я на стороне проекта.
Выбрано и сформировано содержание, утвержден бюджет: дальнейшие перекосы в лояльности руководителя проекта в одну или другую сторону будут создавать отклонения или риски для проекта.
Ваша задача - достижение запланированных бизнес-эффектов и соблюдение договоренностей. На этом и концентрируйте свое внимание.
В каждом проекте есть очень большое количество заинтересованных сторон. Их интересы тесно переплетаются, а порой откровенно противоречат друг другу. Чью сторону выбрать?
Когда мне задают такой вопрос, я отвечаю просто: я на стороне проекта.
Выбрано и сформировано содержание, утвержден бюджет: дальнейшие перекосы в лояльности руководителя проекта в одну или другую сторону будут создавать отклонения или риски для проекта.
Ваша задача - достижение запланированных бизнес-эффектов и соблюдение договоренностей. На этом и концентрируйте свое внимание.
Ваша база знаний - ваш порок?
База знаний по управлению проектами - это признак зрелости проектного управления. Мало какие организации доходят до внедрения этого инструмента. Но база знаний - это в разы возросшая стабильность качества и уверенность в будущем каждого проекта.
В зависимости от бизнеса базы знаний могут содержать
- Шаблоны документов и инструкции по управлению бюджетами
- Правила и рекомендации по выполнению проектов в компании
- Стандартизированные требования
- Результаты работ, достигнутые на предыдущих проектах, аналогичных по своему составу
- Наборы кейсов и лучших практик
Помните при этом - чем детальнее и зарегламентированнее использование базы знаний, тем больше шансов разучиться делать проекты.
База знаний по управлению проектами - это признак зрелости проектного управления. Мало какие организации доходят до внедрения этого инструмента. Но база знаний - это в разы возросшая стабильность качества и уверенность в будущем каждого проекта.
В зависимости от бизнеса базы знаний могут содержать
- Шаблоны документов и инструкции по управлению бюджетами
- Правила и рекомендации по выполнению проектов в компании
- Стандартизированные требования
- Результаты работ, достигнутые на предыдущих проектах, аналогичных по своему составу
- Наборы кейсов и лучших практик
Помните при этом - чем детальнее и зарегламентированнее использование базы знаний, тем больше шансов разучиться делать проекты.
Договор на проект - что включать в него и как
Если вы покупаете или продаете услуги по выполнению проекта, особенно ИТ, вам так или иначе придется заключать договор с подрядчиками на выполнение работ. Что же включать в договор, если многообразие проектных документов таково, что в нем легко можно потеряться?
Обычно, кроме стандартных разделов для договора, включают такие вещи как:
- План-график проекта
- Состав ключевых лиц по проекту
- Требования к составу и наполнению технической документации
- Распределение прав и обязанностей
- Процедуры управления изменениями и простоями
- Процедуры планирования
- В некоторых случаях план управления проектом, хотя это не очень хорошая практика
- ФИО руководителя проекта исполнителя и заказчика
- Порядок предоставления отчетности
В целом правило одно, и оно простое - включайте в договор то, изменение чего вызовет изменение договора.
Таким образом вы защитите себя и свою компанию от того, что что-то пойдет не так как вы запланировали, и будете иметь возможность запустить процедуру управления изменениями легально.
Если вы покупаете или продаете услуги по выполнению проекта, особенно ИТ, вам так или иначе придется заключать договор с подрядчиками на выполнение работ. Что же включать в договор, если многообразие проектных документов таково, что в нем легко можно потеряться?
Обычно, кроме стандартных разделов для договора, включают такие вещи как:
- План-график проекта
- Состав ключевых лиц по проекту
- Требования к составу и наполнению технической документации
- Распределение прав и обязанностей
- Процедуры управления изменениями и простоями
- Процедуры планирования
- В некоторых случаях план управления проектом, хотя это не очень хорошая практика
- ФИО руководителя проекта исполнителя и заказчика
- Порядок предоставления отчетности
В целом правило одно, и оно простое - включайте в договор то, изменение чего вызовет изменение договора.
Таким образом вы защитите себя и свою компанию от того, что что-то пойдет не так как вы запланировали, и будете иметь возможность запустить процедуру управления изменениями легально.
Что такое послойное внедрение?
Есть два варианта перехода к новой архитектуре системы:
1. "Большой взрыв" - все запускается единомоментно
2. Послойный переход - когда запуск происходит частями, при этом какие именно части не имеет значение для целей определения подхода
Понятно, что критически важно выбрать принцип разделения системы на слои. Какие бывают слои.
Организационные (юридические лица, подразделения): это самое простое разделение
Функциональные (склад, бухгалтерия, производство и т.п.): хорошо управляемая структура, так как по каждому элементу есть владелец с конкретным ФИО
Процессные (реализация товара от поиска клиента до закрытия сделки, производственный процесс с учетом обеспечения и отгрузки, закупка от появления потребности до ее закрытия и т.п.): как правило, сложная часть для реализации, так как по одному процессу может быть много ответственных и ни одного консолидирующего менеджера, который мог бы взять на себя разрешение коллизий
Технические (от ограничений ИТ - десять баз данных 1С:УТ потому что ИТ не может обеспечить работу в единой): сложный подход, который приведет или к проблемам в проекте из-за сложного формата поставки результата, или к ошибкам проектирования
Комплексные (пересечение нескольких из описанных выше вариантов): наиболее сложные схемы, так как чаще вбирают в себя негативные стороны и уменьшают влияние позитивных факторов
Когда вы выделите слои, основываясь на каких-то логических принципах, построить логику перехода станет гораздо проще.
Выбирайте слои правильно
Есть два варианта перехода к новой архитектуре системы:
1. "Большой взрыв" - все запускается единомоментно
2. Послойный переход - когда запуск происходит частями, при этом какие именно части не имеет значение для целей определения подхода
Понятно, что критически важно выбрать принцип разделения системы на слои. Какие бывают слои.
Организационные (юридические лица, подразделения): это самое простое разделение
Функциональные (склад, бухгалтерия, производство и т.п.): хорошо управляемая структура, так как по каждому элементу есть владелец с конкретным ФИО
Процессные (реализация товара от поиска клиента до закрытия сделки, производственный процесс с учетом обеспечения и отгрузки, закупка от появления потребности до ее закрытия и т.п.): как правило, сложная часть для реализации, так как по одному процессу может быть много ответственных и ни одного консолидирующего менеджера, который мог бы взять на себя разрешение коллизий
Технические (от ограничений ИТ - десять баз данных 1С:УТ потому что ИТ не может обеспечить работу в единой): сложный подход, который приведет или к проблемам в проекте из-за сложного формата поставки результата, или к ошибкам проектирования
Комплексные (пересечение нескольких из описанных выше вариантов): наиболее сложные схемы, так как чаще вбирают в себя негативные стороны и уменьшают влияние позитивных факторов
Когда вы выделите слои, основываясь на каких-то логических принципах, построить логику перехода станет гораздо проще.
Выбирайте слои правильно
Как проводить интервью - часто встречающийся вопрос.
Собрали в заметки свой опыт
Собрали в заметки свой опыт
👍1
Зачем привязывать требования к процессам?
- Проверить полноту собранных требований
- Идентифицировать противоречия
- Распределить ответственность между владельцами требований и владельцами процессов
- Упорядочить работу с требованиями
- Проверить полноту собранных требований
- Идентифицировать противоречия
- Распределить ответственность между владельцами требований и владельцами процессов
- Упорядочить работу с требованиями
Что такое цифровой двойник?
Цифровой двойник (digital twins) - это модель, которая виртуально представляет собой материальный или нематериальный объект. Это может быть бизнес-процесс или физический объект, например продукт, здание или даже город.
Основные выгоды:
- Оперативный анализ происходящих изменений
- Своевременная передача данных в цифровой двойник помогает в любой момент времени видеть реальную копию объекта
- Рост инноваций через обнаружение необычных закономерностей и связей
- Оптимизация процессов
В части учета на платформе 1С важно учитывать источники данных или потребителей информации. Чаще всего цифровые двойники не затрагивают ни проекты внедрения 1С, ни саму программу
Цифровой двойник (digital twins) - это модель, которая виртуально представляет собой материальный или нематериальный объект. Это может быть бизнес-процесс или физический объект, например продукт, здание или даже город.
Основные выгоды:
- Оперативный анализ происходящих изменений
- Своевременная передача данных в цифровой двойник помогает в любой момент времени видеть реальную копию объекта
- Рост инноваций через обнаружение необычных закономерностей и связей
- Оптимизация процессов
В части учета на платформе 1С важно учитывать источники данных или потребителей информации. Чаще всего цифровые двойники не затрагивают ни проекты внедрения 1С, ни саму программу
Управление проектами 1С
Зачем привязывать требования к процессам? - Проверить полноту собранных требований - Идентифицировать противоречия - Распределить ответственность между владельцами требований и владельцами процессов - Упорядочить работу с требованиями
Как определить процессы?
Зачем нужны процессы - обсудили выше.
А вот как их определить? На самом деле всегда и все определяется целью. Какова цель для нас мы описали раньше.
Итак, есть три несложных шага, как описать процессы, которые нужны нам для автоматизации:
- Определяем первые два уровня иерархии по оргструктуре, это наши функции
- Декомпозируем второй уровень на третий и получаем итог
На каждом уровне есть свой ответственный, владелец процесса. Он-то и будет проверять и принимать наши требования!
#примерыматериалов
Зачем нужны процессы - обсудили выше.
А вот как их определить? На самом деле всегда и все определяется целью. Какова цель для нас мы описали раньше.
Итак, есть три несложных шага, как описать процессы, которые нужны нам для автоматизации:
- Определяем первые два уровня иерархии по оргструктуре, это наши функции
- Декомпозируем второй уровень на третий и получаем итог
На каждом уровне есть свой ответственный, владелец процесса. Он-то и будет проверять и принимать наши требования!
#примерыматериалов
При обследовании выявлена недостаточность серверной инфраструктуры под 1С. Всего 50 пользователей. Что делать?
Вопрос возник не праздно, а рассматривался в реальном проекте. Вопрос поставлен так: писать ли рекомендацию в отчете об обследовании?
Представим, что мы написали рекомендацию и пошли в проект. Как руководитель проекта узнает о том что нужно контролировать этот вопрос? Как работать с классическим возражением клиента - вы же профессионалы!
И есть только одна рекомендация. Посколько клиент не воспринимает эти рекомендации всерьез, наша задача - защитить проект и исполнителя. Для этого идентифицируется риск, проводится его анализ и представляется руководству клиента с вариантами дальнейших событий.
Поскольку вопрос не находится в нашей зоне ответственности и полномочий, мы передаем риск на сторону клиента и включаем режим мониторинга его на каждой статусной встрече или на управляющих советах.
Тогда существенно повышается шанс решения вопроса.
#кейсы
Вопрос возник не праздно, а рассматривался в реальном проекте. Вопрос поставлен так: писать ли рекомендацию в отчете об обследовании?
Представим, что мы написали рекомендацию и пошли в проект. Как руководитель проекта узнает о том что нужно контролировать этот вопрос? Как работать с классическим возражением клиента - вы же профессионалы!
И есть только одна рекомендация. Посколько клиент не воспринимает эти рекомендации всерьез, наша задача - защитить проект и исполнителя. Для этого идентифицируется риск, проводится его анализ и представляется руководству клиента с вариантами дальнейших событий.
Поскольку вопрос не находится в нашей зоне ответственности и полномочий, мы передаем риск на сторону клиента и включаем режим мониторинга его на каждой статусной встрече или на управляющих советах.
Тогда существенно повышается шанс решения вопроса.
#кейсы
Зачем привязывать требования к процессам
Наша задача - убедиться в полноте собранных требований. Простой выход - если клиент не сообщил вам требования, это его проблема.
Правда, тогда вы будете выглядеть в глазах клиента обманщиком
Для нас же привязка требований к процессам - это в первую очередь проверка на полноту и качество собранных требований
1. Если процесс есть а требований нет, повод задуматься
2. Если есть требования но нет процесса, повод задуматься
3. Если ответственный по требованию от клиента и владелец процесса разные, повод задуматься
4. Если все требования у процесса - нетиповой функционал, повод задуматься
5. Если владелец процесса не может подтвердить требования к своим процессам, повод задуматься
Наша задача - убедиться в полноте собранных требований. Простой выход - если клиент не сообщил вам требования, это его проблема.
Правда, тогда вы будете выглядеть в глазах клиента обманщиком
Для нас же привязка требований к процессам - это в первую очередь проверка на полноту и качество собранных требований
1. Если процесс есть а требований нет, повод задуматься
2. Если есть требования но нет процесса, повод задуматься
3. Если ответственный по требованию от клиента и владелец процесса разные, повод задуматься
4. Если все требования у процесса - нетиповой функционал, повод задуматься
5. Если владелец процесса не может подтвердить требования к своим процессам, повод задуматься