Фирма 1С Управление проектами (канал)

НОВИНКА «ИТ-разборы»: реальные проблемы, честный разговор, конкретные решения Коллеги, Запускаем «ИТ-разборы» — живой формат, где мы разбираем реальные рабочие ситуации без скучных лекций и общих советов. Растёте как специалист, но давно застряли в доходе? Получили ответственность без полномочий? Отдел продаж продал невыполнимый проект? Проект буксует, команда конфликтует, а руководитель требует результат «ещё вчера»? Приносите свой кейс. За 30 минут разберём его с двух сторон: — профессиональной: процессы, решения, компетенции и управление; — человеческой: эмоции, мотивация, конфликты и отношения. Определим, где на самом деле возникла проблема, и наметим конкретные шаги, которые помогут выйти из тупика. На одной встрече — два героя, два реальных кейса и опыт всех участников. Хотите стать героем первого «ИТ-разбора»? Опишите свою ситуацию в комментариях. Можно принести и старый кейс, который до сих пор не отпускает. Ваши кейсы будут разбирать Шатохин Дмитрий и Екатерина Махновская, авторы и ведущие бизнес-игр «Пресейл» и «Кризис». Первый «ИТ-разбор» пройдет 14.08.26 в 10.00. Продолжительность – 1 час. Формат: онлайн Стоимость участия в первом ИТ-разборе: бесплатно. Ссылка будет опубликована позднее в этой группе. (!) Зрители смогут комментировать в чате, но не будут участвовать в обсуждении

Добрый день. Вчера опять поиграли в «Пресейл» и я в очередной раз заметила 🔎 Как мы говорим. Даже не то, как мы формулируем мысли, насколько мы косноязычны. А как мы используем слова. Да-да, именно о правильности использования слов хотела бы сейчас написать. Итак, фраза: «Внедряем проект» ❓ Вопрос: Вот как вы думаете, насколько она правильная? ✅ Ответ: Абсолютно неправильная. При этом большее количество человек именно такую фразу используют в диалогах о проектах внедрения ИС. Давайте разбираться 💭 Если обратиться к википедии: «Внедрение – это комплексный процесс запуска/внедрения ИС в работу компании». Проект – это форма организации работ. Т.е. это слово стоит в одном ряду с нашими профессиональными выражениями, ну и в принципе с терминами, определяющими организацию работ: «Работа по заявкам», «Процессный подход» и т.п. Это о том, как мы организовываем исполнение работ. И что же получается… Говоря «Внедряем проект», мы по сути говорим «Запускаем», но ЧТО⁉️⁉️⁉️ Коллеги, будьте внимательны, будьте уважительны к русскому языку, к словам. Правильное выражение «Внедряем ИС» или «Запускаем/исполняем/предлагаем обсудить проект внедрения ИС» и т.д.   P.S. Вот так очень вольным стилем, написала мысли на совсем серьезную тему о языке. Вот такие мы противоречивые – люди ☺️   А какие фразы режут вам слух? Что мы говорим неправильно? ✏️ Поделитесь, нам всем будет полезно проверить себя и поработать над ошибками.

В среду, 29.07 проводим бизнес-игру "Пресейл", посвященную продаже проектов во время кризиса: - как обосновать экономическую целесообразность проекта - преодолеть сопротивление ключевых ЛПР - предложить лучшие условия заказчику без ущерба для своей команды и компании. Начало в 10:00, присоединяйтесь! Ссылка для записи: https://uc1.1c.ru/course/biznes-igra-presejl/?ysclid=mrxfibvp79971026042#description

Коллеги, добрый день. Скорее новость не для всех, но кому-то понадобится. Мои коллеги проводят вебинар «Управление развитием СЭД как комплексный процесс» 30 июня | 11:00 | Бесплатно Спикеры: - Долматова Елена, руководитель группы Методической поддержки проектов, Фирма «1С» - Алхутова Мария, ведущий аналитик группы Методической поддержки проектов, Фирма «1С» О чем вебинар. Познакомим с принципами управлением развития СЭД как комплексного процесса проектах внедрения «1С:Документооборот 3.0» Программа вебинара: 1️⃣Участники процесса развития СЭД 2️⃣Владелец процесса 3️⃣Регламентация процесса «Управление развитием СЭД как комплексный процесс» - сбор требований - валидация требований - дорожная карта - управление бюджетом на развитие СЭД - управление ресурсами - реализация дорожной карты ➡️ЗАРЕГИСТРИРОВАТЬСЯ: https://1c.vkurse.ru/v2/selfregistration?conferenceSessionId=bae34792-5c0c-4a70-adc4-6e3999e64553. Ссылка для подключения будет направлена на указанный при регистрации e-mail

Добрый день. Коллеги, опять хотела бы затронуть вопрос оценки проектов. Мы с вами об этой теме много говорим и рассуждаем. Но, она, как мне кажется одна из самых важных. В этот раз хотела бы поговорить о «глубине» планирования, которая, согласитесь, сильно влияет на качество плана, его реалистичность и, как результат, на качество оценки проекта. Какова же должна быть та самая оптимальная для каждого конкретного случая «глубина» планирования? Нужны ли детали при планировании? И что такое «детали»? Или достаточно ограничиться этапами и планировать «крупными мазками»? Я расскажу свою точку зрения, а вы уточняйте, спорьте, опровергайте или подтверждайте. Как всегда, по пунктам ☺️ 1️⃣ Я сама люблю планировать по принципу «отгадаю мелодию на 7 нот»: этот проект сделаем за 15 месяцев, нам надо 8 спецов, умножаем на ставку, получаем бюджет. Но этот подход только первичный, совсем верхнеуровневый. Используется для формирования ориентира стоимости проекта. 2️⃣ Настоящий план я предпочитаю делать до, скажем так, важных особенностей и нюансов, влияющих на стоимость проекта. Я не люблю расписывать стоимость подготовки ТЗ. В этом случае я скорее скажу – сделаем и согласуем ТЗ за 1,5 месяца, 3 аналитиками + архитектор. А вот продумать вот такие вопросы считаю крайне важными: - будут ли работы по нормализации НСИ? - потребуются ли временные интеграции в случае поэтапного запуска системы? - будет ли «отрисовка» бизнес-процессов, в какой нотации и с помощью какого инструмента? - как будем делать миграцию данных и не скрылась ли внутри проекта необходимость и задача внедрения модуля MDM? - какие работы мы предложим исполнить заказчику самостоятельно, а где требуется его привлечение? - потребуется ли работа в удаленных от проектного офиса точках и кто туда поедет или не поедет, а будет работать на удаленке? И так далее... Это этакие «жизненные» вопросы проекта. То есть подход такой: «я проживаю проект». Да, именно, не планирую виртуальный потенциальный проект, а стараюсь его прожить. «О, Джонни, я хочу, как в синематографе! Прошу тебя – «сделай монтаж» (с) Человек с бульвара Капуци́нов 3️⃣ Но тут вы совершенно логично можете дать замечание, а нужно ли все это показывать заказчику? На мой взгляд – да, нужно. И тут еще раз обращаю внимание, в таком плане детали не про то, сколько займет создание проектного документа (это действительно излишняя и неинтересная для заказчика детализация). В плане фиксируются логически и организационно важные вещи для проекта. И на этапе продажи, считаю, это важно показать заказчику и обсудить с ним ход проекта. Это позволит сформировать правильное понимание проекта, объема и особенностей работ, подготовить заказчика к проекту. 4️⃣ НО‼️ При подготовке к встрече с заказчиком надо задуматься над оформлением документа. Для этого надо понять – кто будет на встрече? каков уровень встречи? И исходя из этого надо подобрать оформление плана. Названия очередей, этапов их длительность, результаты – должны быть продемонстрированы в плане всегда. Нюансы и особенности, рекомендуется выносить в отдельный «стоблец», который можно скрыть, если встреча не предполагает обсуждение деталей и особенностей проекта. Или же открыть для обсуждения нюансов и подробного обсуждения хода проекта. А можно зафиксировать и открытые вопросы под обсуждение. Вот и рассказала, как считаю правильным организовывать работы по составлению плана проекта в рамках продажи. ✏️ Жду ваших мнений – дополняйте, опровергайте, приводите примеры, рассказывайте о практиках. #Рассуждения_о_проектах

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

Коллеги, добрый утро. Знаю, что не все читают комментарии к постам... Хочу поделиться одним из них... Весьма нестандартное видение, видение под другим углом. Но все о том же... ⬇️ Сразу сделаю примечание, что с одни из пунктов не совсем согласна☺️ И не согласна с пунктом «продолжать только не проекты, где …». РП человек «подневольный», решение принимает директор. Тут важна эскалация и инициация остановки или заморозки проекта.

Добрый день. Небольшой комментарий в самом начале... Коллеги, никогда к проектам не относилась как к "бою", считаю, что проект это "созидание". Но когда писала этот пост именно эта цитата крутилась в голове. Она все-таки очень про РП ☺️ Этот пост навеян новым потоком обучения по управлению проектами. Рассказывала пока еще только про фазу продажи проекта. И уже получила такой вопрос: «И что это все должен делать РП❓». Так что же должен делать РП? Давайте порассуждаем. Стандартные задачи, которые мы все знаем: 〰️ участвовать с предпроектном обследовании 〰️ участвовать в формулировании требований 〰️ планировать потенциальный проект: составлять и дорожную карту проекта, и планировать ресурсы на исполнение, и формировать бюджет 〰️ участвовать в разработке проекта договора Но есть еще вспомогательные, без которых потом будет сложнее: ✅ формировать понимание того самого потенциального проекта у заказчика – хода проекта, ответственности сторон, результатов ✅ формулировать ограничения и допущения проекта и при переговорах с заказчиком обсуждать эти ограничения, опять же чтобы сформировать правильное понимание проекта ✅ стараться понять цели и задачи проекта – не только формальные, но и неформальные: то что на бумаге не напишешь, но то, от чего зависит успех проекта ✅ внимательно присматриваться, «крутить головой на 360», чтобы понять состав команды со стороны заказчика, мотивы участников, цели, интересы, мотивацию, взаимное влияние, зависимости, статусы, признание, вес слова в коллективе и т.д. Все что пригодится в плане психологии при управлении проектом Коллеги, ничего важного не упустила? Или такой подход при продаже проекта кажется избыточным? #Рассуждения_о_проектах

Коллеги, добрый день. Сегодня хочу затронуть тему не про управление непосредственно, а про проект – про его функциональные области. В последнее время сталкиваюсь, как мне кажется, в некорректным трактованием функциональной области «Документооборот». Постараюсь правильно описать ситуацию… Почему-то часто бытует представление, что документооборот – это просто программный продукт «Документооборот» с набором функций, которые можно использовать в рамках автоматизации процессов компании. И в рамках проекта специалисты, говоря о документообороте, рассуждают именно о функциях, которые присущи программному продукту. То есть «как настроить процедуру согласования заявки на оплату», «как настроить процедуру утверждения и подписания договора» и т.п. Задачи верные. Но это скорее этакое локальное и частичное использование «полезных» функции программного продукта. ☹️ Как, мне кажется, такое направление взгляда на область «Документооборот» не верное. Давайте разбираться почему… Начнем с программного продукта. Конечно, Фирма 1С в своем портфеле имеет сильный программный продукт «1С:Документооборот». Его функциональность детально описана во многих источниках и включает модули: • Работа с договорными документами • Управление документами • Управление процессами • Почтовый клиент • Учет и планирование рабочего времени • Даже проектный учет (на всякий случай даю ссылку https://v8.1c.ru/doc8/) ‼️ НО‼️ Говоря в проекте о функциональной области «Документооборот», надо понимать, что она не ограничивается только локальным использованием функций программного продукта. Говоря о функциональной области, мы должны говорить не о системе, а о бизнес-процессах. Ведь первичны-то бизнес-процессы, а система является лишь инструментом для организации и поддержки этих процессов. Что же входит в функциональную область «Документооборот»? 1️⃣ В рамках общего делопроизводства: • процессы работы с корреспонденцией: входящие и исходящие письма • процессы работы с внутренними документами: организационно-распорядительные документы, локальные нормативные акты, служебные записки, протоколы) • процессы работы с договорами 2️⃣ В рамках общего делопроизводства: кадровые приказы и трудовые договоры 3️⃣ Также контур специального/производственного делопроизводства: «первичка», финансовые документы, производственные документы 4️⃣ Ну, и ведение номенклатуры дел Теперь надо понять, кто является заказчиком и пользователем системы. ✅Давайте вспомним, что на любом предприятии есть Канцелярия. Именно этот отдел является основным организатором, управленцем процесса «Документооборот». ✅Помимо этого, вся компания «пронизана» процессами документооборота – созданием, согласованием, регистрацией, исполнением и хранением документов. Поэтому пользователями тех или иных функций системы «Документооборот» являются все отделы компании. ⁉️ Что же происходит на практике❓ Чаще всего в проектах мы затрагиваем лишь контур специального/производственного делопроизводства. При этом говорим о нем, не как о процессе, а как о наборе локальных функций программного продукта – надо согласовать, надо подписать, вот этот акт, вот эту накладную, вот этот отчет. 🔔 В этом посте я же хотела бы обратить ваше внимание на то, что функциональная область «Документооборот» - это целый предметный блок, включающий свои процессы, опирающийся на нормативные государственные акты, требующий при внедрении наличия предметной квалификации в данной области. #Предметные_вопросы

Добрый день. Уже 9 июня 2026 года стартует новый поток обучения "Управление проектами на основе 1С:ТКВ 2.0". Курс проходит в онлайн формате, еженедельно по вторникам в 10:00 по МСК. В рамках курса: 1️⃣ Будем рассуждать о том, что такое "Управление проектами". Кто же управляет проектом? Кто в команде ведущий, а кто ведомый? Или важен альянс, союзничество, партнерство? 2️⃣ Рассмотрим очень подробно жизненный цикл проекта создания и внедрения ИС: какие работы должны быть исполнены, какие документы должны быть написаны, на что следует обращать внимание при исполнении работ, какие существуют риски и "подводные камни" на каждом этапе проекта 3️⃣ И конечно, обсудим структуру проектной команды Ссылка для записи и подробная программа курса ⬇️ https://uc1.1c.ru/course/upravlenie-proektami-na-osnove-1s-tehnologii-korporativnogo-vnedreniya-2-0/ #Обучение_РП

Коллеги, здравствуйте. Вот и закончился мой отпуск 🥹 Я побывала в восточной сказке ☀️ очень красиво, тепло, песчано. И вкусно))) Ничего общего с проектами ☺️ Точнее, даже не хочется искать это общее))) Начинаем работать 🙂

Коллеги, добрый день. Я с новостью. Мы разработали для Вас схемы прохождения курсов по 2 направлениям: 1️⃣ Руководитель проектов/Руководитель проектного офиса 2️⃣ 1С:Аналитик Схемы размещены на сайте УЦ-1 Вот так - кратенько☺️ #Обучение_РП

Коллеги, добрый день. Поделюсь... Я ведь же тоже учусь 🤓 И вот только закончила, прямо сегодня, слушать наш же курс "Управленческий и финансовый учет проектов". Отличный курс 👍, про то как должен быть выстроен учет в области управления проектами! Курс полностью пересекается с моим курсом "Как построить проектное управление в фирме-франчази", но открывает многие вопросы именно в разрезе "Как организовать учет". 💯 ✅ Рекомендую Кстати, я то смотрела записи, а сам курс скоро начнется - 26 мая 2026 года. Тем кому интересно - записывайтесь. Там: 1️⃣ и про управленческую себестоимость и расчет ставок специалистов 2️⃣ и про бюджетирование проектов 3️⃣ планирование и учет трудозатрат 4️⃣ рентабельность проекта и управленческую отчетность 5️⃣ куда ж без договоров и контроля исполнения 6️⃣ ну и инструменты проектного управления конечно Ссылка для записи #Обучение_РП

Добрый день. Продолжаем ранее начатую тему ⬇️ Хочу поделиться с вами интересным документом, который попал ко мне в работу. Это проект "Принципов внедрения 1С", сформулированных командой заказчика. Это не техническое задание и не смета, а именно попытка сформировать "правила игры". ⚠️ Принцип №6 "Скорость выполнения операций и типовой функционал" Кратко: Сделать не хуже чем в исторической системе. Скорость работы пользователя в 1С:ERP не должна превышать аналогичную работу в исторической системе. Стимулировать использование типового функционала. Для договора: Подрядчик обязуется обеспечить, что совокупные трудозатраты пользователей на выполнение операций в разрабатываемой системе (как типовых, так и доработанных) не превышают трудозатрат на выполнение аналогичных операций в исторической системе. При этом Стороны исходят из того, что типовой (неизменённый) функционал платформы 1С:ЕРП по умолчанию соответствует данному требованию, если Заказчиком не доказано иное. Если Подрядчик предлагает реализацию функции нетиповым способом (путём доработки), он обязан при согласовании перечня работ (Принцип №5) письменно подтвердить, что такая реализация не приведёт к превышению указанного порога трудозатрат. В случае последующего выявления превышения по вине нетиповой реализации Подрядчик устраняет его за свой счёт, а также компенсирует Заказчику расходы на проведение замеров. Если в ходе эксплуатации Заказчик направит мотивированный запрос о превышении указанного порога, Стороны в рабочем порядке проводят совместное мероприятие (замеры, анализ, экспертную оценку) для проверки обоснованности обращения. Формат, сроки и методика проведения мероприятия определяются Сторонами по взаимной договорённости при получении запроса. В случае подтверждения факта устойчивого (не разового) превышения трудозатрат пользователя, Подрядчика за свой счёт выполняет работы по оптимизации системы. Если превышение вызвано изменением исходных требований, аппаратного обеспечения или иными обстоятельствами, независящими от Подрядчика, Стороны обсуждают возможность доработок на условиях дополнительного соглашения. 💬 Коллеги, давайте обсуждать #Рассуждения_о_проектах

Здравствуйте, коллеги. Для вас уже не секрет, что мы постоянно проводим бизнес-игры. Отличный формат обучения, выявления зон роста для каждого участника индивидуально. Почему индивидуально? А потому, что в ходе игры, каждый участник «показывает» себя – ведь такой уж это формат ☺️ И это позволяет тренерам поработать хард и софт-скиллс с каждым участником индивидуально. Но я-то участвую в играх, как наблюдатель. Стараюсь собирать и обобщать, систематизировать… И хочу с вами поделиться некоторыми выводами относительно того, какие зоны являются самыми непроработанными. И, на самом деле, я сама удивляюсь этим выводам, так как кажется, что это основное!!! 1️⃣ Часто путаются в жизненном цикле проекта – какие этапы нужны в проекте, зачем они нужны, какие работы выполняются в рамках каждого этапа. Т.е. по сути, не могут проработать жизненный цикл проекта, предложить его заказчику и, самое главное, пояснить и обосновать его для заказчика. 2️⃣ Деталь. Планируют и презентуют заказчику работы по описанию процессов, а нотаций не знают. Не до деталей, нет, а иногда даже правильных названий нотаций. 3️⃣ Путаются в понятии «Функциональный разрыв». Кажется, таком популярном в настоящее время. 4️⃣ Управленцы часто не умеют делегировать. Пытаются закрыть все вопросы сами. А в результате – провал, т.к. не знают (см. выше) нотаций, планов работ и целей исполнения работ и т.д. Итог тут печальный – провал встречи. 5️⃣«Неумение ставить на паузу». Поясню, ситуация… Заказчик задает вопрос, но ответа сразу нет. Вместо того, чтобы сказать «Ваш вопрос крайне важен, но в настоящий момент ответить на него сложно, (например) т.к. у нас на встрече нет предметника в данной области. Мы вернемся в офис, обсудим и отправим вам ответ письмом». Ведущий встречи начинает что-то отвечать, плавать в вопросе и, в результате, демонстрирует некомпетентность. Итог тот же самый – провал встречи. Просто поделилась… Коллеги, надо учиться, всегда надо учиться – не останавливаться… Даже когда кажется, что знаешь все и все умеешь – ведь всегда есть зоны улучшения… И пост был не рекламный, но все же… Приходите учиться. Наши курсы и бизнес-игрыпо управлению проектами А тут есть классные темы по хард и софт-скиллам. #Обучение_РП

27 апреля 😮 «У природы нет плохой погоды» (с)