История одного провала внедрения 1С:ERP 2 по классической технологии. С последующим спасением по Scrum

Публикация № 911946

Методология - Управление проектом

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

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

Акцент будет сделан на управленческой части, хотя с точки зрения использования прикладных решений, мой доклад во многом перекликается с докладом Андрея Овсянкина и его подсистемой Yellow RabbitMQ. В практике “БИТ:ERP” мы начали использовать эту подсистему именно на этом проекте – на провальных проектах очень многое меняется, и ты учишься на них гораздо больше, чем на успешных.

 

О проекте

Речь пойдет о реальном проекте внедрения «1С:ERP 2» на сети оптовых нефтебаз и заправок.

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

Компания обслуживает почти полторы сотни заправочных станций и большое количество резервуаров.

Проектом занимались мы, направление «Практика “БИТ:ERP”». Коротко об особенностях нашей работы.

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

Коротко о самом проекте – это внедрение практически всех подсистем «1С:ERP» и написание своего модуля учета нефтепродуктов.

Автоматизируемая отрасль имеет определенную специфику, поэтому использовать для учета полностью типовой 1С:ERP невозможно, но участки расчета себестоимости и регламентированного учета мы в конфигурации не меняли. Главной задачей этого проекта была разработка с «нуля» модуля оперативного учета нефтепродуктов, который генерировал уже типовые документы.

Здесь перечислены программные продукты, с которыми нам пришлось работать.

Расскажу про основные вехи проекта:

  • В ноябре 2015 года мы бодро и амбициозно начали свою работу. С точки зрения методологии мы использовали классический «каскадный» подход, который всем дорог и близок – большую часть своей сознательной деятельности я внедрял проекты по «каскаду».
  • К февралю 2016 мы закончили проектирование. На этом этапе мы в рамках лучших рекомендаций по каскадному подходу использовали прототипирование, потому что увидеть всегда лучше, чем прочитать – мы для своих проектов всегда делаем контрольный пример (или, как его еще называют, функциональную модель).
  • Параллельно мы начали разрабатывать – так делают практически в любом проекте по «каскаду». И к апрелю 2016 года мы завершили разработку системы.
  • К маю 2016 у нас с точки зрения интегратора уже все было готово: мы завершили проектирование системы, подписали проектное решение, завершили разработку, провели тестирование, получили замечания, исправили их, подписали акты и даже завершили обучение пользователей. Причем, у нас было заложено не только обучение, но и аттестация – мы все это завершили.
    Но была одна небольшая проблема, причем не у нас, а у заказчика. Систему, которую он заказал, спроектировал, согласовал и протестировал вместе с нами, нельзя было запустить в эксплуатацию от слова «никак». Если брать каждый конкретный блок, то в соответствии с изначальной постановкой задачи все работало хорошо, но запустить всю систему целиком было невозможно. И директора филиалов достаточно подробно и живописно, используя богатую ненормативную лексику, на примерах объясняли нам, почему так нельзя сделать. В итоге мы запустили только блок «Казначейство», а по всему остальному заказчик принял решение «откатиться» на исторические системы.
  • Потом где-то в течение месяца был перерыв, когда никаких активных работ мы не вели. Заказчик придумывал, как у нас отсудить деньги. Мы с ним вяло дискутировали, спрашивая, какие есть претензии «к пуговицам», на что он отвечал, что «к пуговицам» претензий как раз нет, проблема в том, что система не работает. Так мы и общались. В это время заказчик вел переговоры с другими командами внедрения, и, наверное, понял, что найти свободную команду с опытом внедрения ERP, которая сможет предложить что-то альтернативное, не начиная то же самое еще раз (не проводя заново проектирование, разработку и т.д.) у него вряд ли получится.
  • В итоге финансовый директор (спонсор проекта), пригласил нас на встречу и задал достаточно простой вопрос: «Хорошо, а что вы можете предложить?». Надо сказать, что у меня до этого момента ни разу не было ситуации, чтобы система не запустилась вообще. Были случаи, когда «плевали в спину», но систему все равно, сжав зубы, использовали. А здесь возникла ситуация, что время и деньги уже были потрачены, но система в эксплуатацию так и не запустилась. 60% бюджета мы на тот момент уже «съели», было понятно, что на очередной эксперимент заказчик столько же денег уже не даст и сроки были даны короткие. Этих двух моментов было достаточно, чтобы я начал смотреть в сторону Agile и Scrum, потому что там заявлялось, что проект можно сделать в короткие сроки и с ограниченным бюджетом. В итоге заказчику было сформулировано предложение о том, что мы попробуем запустить часть функциональности без увеличения бюджета, и, если система заработает, то с вменяемым увеличением бюджета мы сможем запустить ее целиком.
    В первоначальные сроки мы уже тогда не вписались, потому что запустить систему нужно было в апреле, а мы находились в июне и «машины времени» не существует. Но мы решили, что нужно попробовать, тем более, что деньги еще оставались, и другого выхода ни у заказчика, ни у нас тогда не было. А когда нет выхода – резко стимулируются инновации.
  • Дальше все пошло гораздо бодрее. Конечно, были и проблемы – когда ты в ситуации катастрофы внедряешь новую технологию, говорить, что нет проблем – это неправда. Ночью я читал книги и статьи в Google о том, как можно решить наши проблемы, а утром пытался применять прочитанное – в результате получал обратную связь от сотрудников, они мне что-то предлагали. Дальше я опять углублялся в изучение той документации, которая есть в интернете и книгах – это происходило циклически. Всегда оказывалось, что все наши проблемы не уникальны, и их уже лет 10 назад 150 раз обсудили на форумах. Нам это сильно помогало, потому что когда ты формулируешь проблему – этого достаточно, чтобы ее решить. Просто выбираешь потом из нескольких вариантов то решение, которое тебе больше всего нравится, и используешь.

 

Инструменты

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

 

Дорожная карта

Начнем с «дорожной карты».

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

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

Это доказывает, что Scrum можно и нужно применять на проектах внедрения ERP. Я часто слышу утверждение, что Scrum – это хорошо, это круто, но использовать его в ERP при внедрении бухгалтерского учета невозможно, потому что там важен баланс и функциональность счетов по отдельности не запускается. Но я показываю, что это возможно и мы в реальной жизни так делаем.

 

Инструменты взаимодействия внутри команды

Перейдем к взаимодействию. Я уже упоминал, что в нашей команде работают удаленные сотрудники из разных часовых поясов. Что было сделано в рамках коммуникаций? Это не относится непосредственно к Scrum, но Scrum нас к этому подстегнул.

  • Были запрещены любые средства коммуникации, которые использовались до этого: E-mail, Telegram, Viber, WhatsApp – все системы, которые использовались сотрудниками для общения между собой.
  • Skype мы оставили только для голоса и видео.
  • Все общение мы перенесли в корпоративный мессенджер Slack. Раньше, когда на проект приходил новый сотрудник, он обычно не понимал, что происходило на проекте ранее: кто над ним работал, какие работы велись по его блоку (по «Складу», по «Казначейству», по закрытию месяца) – вообще ничего. Только со временем другие сотрудники, узнававашие, что есть новый консультант и его неплохо бы держать в курсе по вопросам «Казначейства», начинали включать его в копию переписки. Причем, когда в копию добавляли всех сотрудников (чтобы все были в курсе), почтовый ящик превращался в нечто неуправляемое. По нескольким параллельно идущим большим проектам у меня в пике приходило по две тысячи сообщений в день, причем это только по проектам, не говоря уже про все остальные переписки. Ознакомиться с таким потоком сообщений было невозможно. И практически невозможно было отфильтровать все это и понять: что тебе действительно важно и срочно нужно; что просто важно, но не срочно; а что можно и не читать. Slack позволил решить эти проблемы, поскольку он имеет несколько ключевых достоинств:
    • Все общение в Slack можно разбить на тематики. Если у тебя есть система, где все общение разбито по тематическим каналам, и сотрудники при написании сообщений привыкли разграничивать, в рамках какого канала обсуждаются те или иные темы, любой сотрудник может подписаться на интересные ему каналы.
    • В Slack есть гибкая настройка уведомлений, т.е. если тебя лично упомянули, ты получаешь приоритетное уведомление.
    • Есть множество возможностей, которые позволяют фильтровать поток информации и читать только нужные сообщения.
    • Slack устанавливается на телефон, iPad, Android-планшет и т.д. Это очень удобная система, хотя есть аналоги, например, HipChat от Atlassian и множество других продуктов, в том числе и бесплатных, которые позволяют делать то же самое.

Вот так выглядит интерфейс Slack – это скриншот общения по закрытию месяца.

Дальше – Wiki-система. Опять же, Wiki-систем много как платных, так и бесплатных, на все случаи жизни. Мы выбрали Confluence и перешли на документирование системы только в рамках Wiki, т.е. у нас все документы готовятся не в Microsoft Word, а в Wiki-системе Confluence. Причем, Confluence у нас связана с Jira, где с помощью Wiki мы описываем постановку задачи.

Дальше, Jira – в ней мы храним backlog и отслеживаем все задачи. В Jira у нас «живут» все: и разработчики, и консультанты.

Есть несколько правил по ведению backlog’а:

  • Первое правило – это то, что все задачи по одному проекту должны быть в рамках одного backlog’а.
  • Второе правило – backlog должен меняться, т.е. когда у нас есть список функциональных требований и он с начала до конца проекта не меняется – это неправильно.
  • Третье правило – backlog всегда ориентирован на бизнес. Любая задача должна объяснять, какой выигрыш она принесет конкретным пользователям. Если этого не получается, надо очень сильно подумать – нужна ли эта задача, или от нее можно отказаться. Либо нужно переписать эту задачу так, чтобы она несла конкретную пользу. Это – «первое правило бойцовского клуба».
  • Но на первое правило всегда есть и второе, которое оправдывает наличие тех редких случаев, когда задача конкретной пользы бизнесу не несет. Это правило касается управления техническим долгом. Здесь наша практика подтверждает общемировые тенденции: 10-20% задач в backlog’е относятся к техническому долгу.

Вот так выглядит реальный backlog с проекта разработки «коробки» «БИТ:MDM». Здесь показан не весь backlog, а только его часть.

  • Цветные лейблы справа – это эпики, на которые мы делим всю нашу разработку.
  • Дальше идет список задач.
  • Аватарки – это фотографии потенциальных исполнителей по этим задачам. Поскольку задачи еще находятся в backlog’е, и работы по ним пока не ведутся, то это только предполагаемые исполнители. Но если мы знаем, что лучше, чтобы эту задачу выполнил конкретный сотрудник, то его мы и назначаем ответственным.

 

Как мы планируем спринты

Как мы планируем спринты?

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

На слайде показан пример такой Wiki-страницы.

Здесь вы можете видеть скриншот плана спринта с реального проекта – это всем известный Scrum Board. Эта страничка, кстати, является обязательным атрибутом нашего процесса управления проектом. Она должна быть всегда, и каждый пользователь Jira, даже если он в этом проекте не участвует, всегда может с ней ознакомиться. Для нас это своеобразный Best Practices.

 

Stand-up

Очень важная проблема, о которой нужно рассказать – это ежедневные стендапы (их еще называют «ежедневный Scrum» или «летучка»). Согласно технологии Scrum они должны укладываться в 15 минут. Мы, прочитав все книжки, поняли, что в составе команды должно быть не более семи человек, и разделили один большой проект на несколько команд, но в 15 минут мы ни разу не укладывались.

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

Мы нашли для этого очень простое решение и стали проводить стендапы в «гибридном» режиме:

  • Все участники перед совещанием пишут в Slack ответы на вопросы «Чем занимался вчера?», «Чем буду заниматься сегодня?» и «Какие препятствия есть?».
  • И на стендапе мы обсуждаем именно то, что должны обсуждать – препятствия к выполнению задач.

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

  • Он стучится в Slack каждому участнику проектной команды и пишет персональное сообщение: «Что ты делал вчера по этому проекту?».
  • Кроме этого, он не обидчивый. Если сотрудник занят и не может ему ответить, бот через некоторое время спрашивает опять: «Чем ты вчера занимался?». И так потихоньку с возрастающей регулярностью «достает» сотрудника до начала стендапа.
  • Если человек с ботом не договорился, подключается руководитель проекта, который объясняет, что игнорировать бота – это плохо. В любом случае, ситуация «Я забыл сделать отчет» у нас исчезла.
  • Чем еще хорош бот – он очень хорошо умеет делать гениальные отчеты и никогда не «косячит» – отчет отображает именно те данные, которые нужно.
  • По каждому конкретному проекту автоматически наполняется канал, где для каждого сотрудника четко написано, что он делал.

Если у вас используется Slack – попробуйте этого бота, я всем рекомендую, это очень удобно. А если у вас используются другие программные продукты, обязательно найдите для них что-то аналогичное или сделайте сами. У нас есть идея разработать это на 1С, но пока руки не дошли.

 

Демо

Как мы проводим демо?

  • Первое правило – даже если на демо показывать нечего, мы собираемся и обсуждаем, как так получилось, что за две недели разработки нашего «коробочного» решения нам нечего показать. Конечно, можно придумать множество причин, почему демо не нужно показывать:
    • Например, потому что к нему надо долго готовиться, а если мы не подготовимся, то ничего работающего показать не сможем.
    • Или потому что мы на демо убиваем много времени, а надо кодировать.
    • Если спросить участника проектной команды, почему надо отменить это конкретное демо, он придумает 10 железобетонных причин, каждая из которых в отдельности будет не глупой отговоркой, что «я плохо себя чувствую», а вполне обоснованным, привязанным к бизнесу аргументом – например, что когда проводим демо, мы теряем деньги и т.д.
  • Но демо проводить нужно, потому что именно на нем выясняется, что у нас ничего не работает и рассказы о том, что работает – это вранье. Существует «эффект демо» – когда до демонстрации все работало, а на ней вдруг почему-то работать перестало. Разработчик начинает что-то показывать и у него задача за задачей «отваливается», не работает – это производит гнетущее впечатление. Конечно, всегда можно оправдаться, почему это сейчас не заработало, но когда для десяти задач находится десять оправданий – значит, что-то пошло не так.
  • Демо мы проводим всегда. И с каждым разом оно улучшается.
  • Главный лозунг демо – это «Demo or die», т.е. или «Проведи демо или умри». Демо – это обязательно, дисциплина здесь является ключевым фактором.

 

«Разбор полетов»

В конце спринта мы проводим «разбор полетов» – так называемую «ретроспективу». На слайде показан примерный порядок такого «разбора».

 

С чего начать?

С чего начать, если вы хотите применить Scrum?

Первый вариант, самый лучший – это прийти к нам работать. Вы научитесь применять Scrum и использовать его на реальных проектах внедрения ERP.

Второй вариант – вы можете поучаствовать в демо (к сожалению в связи со сложностью администрирования процесса от данного варианта решили отказаться) нашего проекта разработки «БИТ:MDM», оно у нас проходит в Skype, т.к. у нас удаленная команда разработки. Это открытое приглашение поучаствовать – пишите мне, я вас добавлю без проблем. Единственное условие – участвовать можно только в режиме слушателя, т.е. отключайте микрофон и слушайте, что происходит, не комментируя происходящее.

И третий вариант – это прочитать статьи. Я сделал подборку статей, которая мне помогла, могу поделиться (gleb@stalnoy.ru).

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Max27 7 01.10.18 11:25 Сейчас в теме
Спасибо за подробный разбор!)
2. katenok86 244 01.10.18 12:15 Сейчас в теме
А можно на примере пусть и обобщенно как запускается рег учет по скрам. Дорожная карта это хорошо, но не могу на деле понять как это происходит. При условии что в ерп весь регл учет по всем счетам должен начать вестись с начала года, не понимаю как это организовать
3. acanta 01.10.18 12:43 Сейчас в теме
(2) 1. Банк-касса
2. Кадры-Зарплата
3. ТМЦ - Взаиморасчеты
4. Прочее
5. Баланс
6.Фин.рез
В древние времена баланс вносили общими суммами по счетам без аналитики. В ЕРП можно запустить сначала оперативный контур, с выгрузкой данных в учетную систему, затем в ерп закрыть период и перевнести остатки.
5. katenok86 244 01.10.18 12:48 Сейчас в теме
(3)А на этапе перехода с 1 на 3 например что делается с остатками по тмц и взаиморасчетам? которые ранее накопились? До окончания до 6 пункта учет дублируется в 2 -х программах? старой и новой?
7. katenok86 244 01.10.18 12:55 Сейчас в теме
(3)Я понимаю запуск отдельно оперативного складского контура и производства, а потом бухгалтерского. Это мы проходили и по водопаду. Но вот прм по счетам. Это слабо представляю. Особенно если сейчас клиент работает в нормальной учетной системе, галактике например.
Dmitri93; +1 Ответить
25. glebushka 242 02.10.18 13:14 Сейчас в теме
(2) При запуске по скрам руководствоваться следующими принципами:
2.1. Единый источник правды: Никакого параллельного учета никогда допускать нельзя. Не бывает двух основных учетных систем. В одну (и, скорее всего, старую) будут забиваться данные нормально, а в другую - по мере возможности (а её никогда нет). Это если не говорить о том, что аналитики могут не совпадать, принципы учета могут изменится, да тупо алгоритмы в коде разные реализованы.
Так что да, будут интеграции. Передача справочников/документов.
2.2. Переходить так, чтобы * на предыдущее состояние был очень затруднен или, лучше, невозможен. О причинах подробно расписал 2,5 к лет назад товарищ Сунь-Цзы.
2.3. В любой непонятной ситуации начинайте со справочников. Для этого можно использовать как отдельную систему (мы под это запили целый тиражный продукт БИТ:MDM), так и вести справочники в транзакционной системе (мы успешно используем и тот, и другой подходы)
2.4. Интеграции должны быть быстрыми (для пользователей "реальное время") и надежными (асинхронными). Придется использовать брокер. Мы для того чтобы делать интеграции оперативно и не раздувать бюджет проекта запилили БИТ:Адаптер 3. Но, в целом, никто не мешает повторить подвиг, купить компоненту Yellow Rabbit и запилить всё самим. Дольше и дороже, но экспы больше :)
Ну а дальше всё по ситуации, что больше болит у клиента, что проще интегрировать. Обычно это Казна, Закупки, склад, Продажи ну и т.д.
Пока внедряете блоки, выгружаете документы из новых блоков новой системы в старую систему. Именно по документам. Если запустили склад, то деньги у вас не важно, идут или нет. Важно чтобы количество шло. В этому случае суммы - дело наживное :) Ну т.е. всё в рамках разумного.
А далее наступает заветное 01 января. И в старую систему документы за новый год не грузятся. А все переходят на новую систему.
Разумеется всё это сработает, если у вас есть возможность дорабатывать старую систему. Но я пока не встречал заказчика с 1000 пользователями в базе, у которого бы не было бы своего ит-отдела на допилке старой системы и, дополнительно, очень часто, ещё и нескольких подрядчиков.
(7) По Галактике опыта перехода нет. Сейчас делаем большой проект по переходу с Аксапты. Крупный торгово-производственный географически распределенный холдинг. Думаю, опубликуем материалы по результатам в 1-2 кв. следующего года
(12) (19) (22) Мы сделали систему так, как сказали ответственные представители Заказчика. А оказалось что это не только не то что нужно, а вообще не жизнеспособно, поскольку мало коррелирует с реальностью. Обычно на проектах жизнеспособность мы хоть как-то контролируем за счет наличия типовых решений и предыдущего опыта в той же отрасли. А так получилось что ни одного отраслевого решения нет (а то что есть - это совсем не то, да и для другого масштаба), и опыта у команды в оптово-розничной торговле нефтепродуктами не было. Возможно, если бы мы внедряли типовой продукт, и имели бы за плечами аналогичный проект, то всё бы сложилось иначе.
Конкретно нам сказали, что типовые документы финансового и товарного учета ЕРП - это ок, добавьте только реквизиты там, там и там. И чуть формы печатные поправьте, и всё ок будет. А потом, ВНЕЗАПНО, оказалось, что, без оперативного учета вообще никак. Причем не того, который в типовой, а своего, отдельного.
Например, есть операция перемещения топлива с нефтебазы на АЗС. А вот кому принадлежит топливо ты узнаешь только после того как заправишь, может быть и возврат с ответ хранения, и реализация собственного. Дальше ВНЕЗАПНО оказалось, что есть ещё много удивительных историй, с какой детализацией должны вестись остатки, обороты по оперативному учету. И что есть ещё внутренние перекидки между филиалами. Т.е. мы должны отразить что на нефтебазе такого-то филиала хранится топливо, принадлежащее клиенту, причем сам клиент этот другого филиала и остатки нужно учесть именно в рамках другого филиала для целей бух. учета. Я уж не говорю о том, как стремительно и внезапно менялись составы реквизитов документов. И что поступление по жд это одно, по воде другое, авто третье, а трубопровод четвертое. Покупаем цистерны, меряем литры, учитываем в тоннах, продаем в литрах, килограммах, причем по нескольким плотностям. В общем там реальное веселье.
(18) да там проблем с согласованием как раз особых не было :) Проблема была в том, ЧТО согласовали, вернее что требовали сделать
(16) Проблема в основном была в "ответственных" Заказчика. Они могли долго и упорно что-то доказывать, и рассказывать как "на самом деле" (с) всё работает, и бумага она такая, всё стерпит. А вот как только система сталкивается с реальностью, там уже ничего доказывать не нужно. Как говориться, счет на табло. Даже спорить не нужно. Если не работает, то нужно переделывать, вне зависимости от того, какая стройная теория, и насколько уважаемый человек, который её продавливал. Т.е. систему запустили за счет того, что исходили из принципа "все врут" (с) Доктор Хаус, поэтому все гипотезы тут же тестили на практике. В итоге вместо многомесячной разработки проверяли гипотезы за неделю-две на PSP, реже MVP.
(21) да, этот фактор тоже имел место быть
zxcvb98765; katenok86; acanta; +3 Ответить
27. DDA4746 02.10.18 15:42 Сейчас в теме
(25)
Проблема в основном была в "ответственных" Заказчика. Они могли долго и упорно что-то доказывать, и рассказывать как "на самом деле" (с) всё работает, и бумага она такая, всё стерпит. А вот как только система сталкивается с реальностью, там уже ничего доказывать не нужно. Как говориться, счет на табло. Даже спорить не нужно. Если не работает, то нужно переделывать, вне зависимости от того, какая стройная теория, и насколько уважаемый человек, который её продавливал. Т.е. систему запустили за счет того, что исходили из принципа "все врут" (с) Доктор Хаус, поэтому все гипотезы тут же тестили на практике.


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

Если заказчик страдает управленческой импотенцией - эджайл его спасет (возможно). А можно и водопад запланировать с учетом вероятных "скрытых работ" на всех этапах; иногда это удобнее, т.к. водопад лучше продается.
28. glebushka 242 02.10.18 15:55 Сейчас в теме
(27) не понимаю, как в рамках каскада можно получить быструю обратную связь от пользователей, которые используют в систему в реальных своих процессах, а не на бумаге. Быстрая обратная связь позволяет не работать "в стол" и не тратить энергию на "кабинетные" дискуссии. Единственный критерий истины - это реальная эксплуатация системы.
Что касается продается. Это правда. Каскад продается бОльшему числу клиентов, и проще чем скрам. Но мы сейчас осознанно решили жертовать продаваемостью для того, чтобы лучше фильтровать входящих клиентов. Пока, вроде бы правы. Качество клиентов у нас в подразделении улучшилось. Работать приятно. Видны результаты. И понятно для чего мы это всё делаем.
29. genayo 02.10.18 16:24 Сейчас в теме
(28) То есть, вы выбираете проекты, на которых скрам будет работать, и не берете те, где не будет.
32. DDA4746 03.10.18 10:25 Сейчас в теме
(28) Все зависит от характера проекта. Если идет автоматизация существующих процессов - обратная связь при разработке критична. Если же внедряем что-то новое, либо радикально меняем существующее - сначала продумываем, как делать правильно, а потом продавливаем исполнителей делать как сказали, а не как они привыкли. Возникающие при этом проблемы решаем по мере выявления.

Но второй вариант за более чем 10 лет мне встретился лишь однажды, когда наша компания "рейдила" один разваленный МУП. Была позиция генерала по отношению к "старой гвардии, всю жизнь на транспорте": "не рассказывайте моим людям, как работать, своими методами вы довели предприятие до разрухи. Теперь делайте как говорим мы". Результат - рост выручки за 6 месяцев в 5 раз на той же производственной базе теми же людьми; за полгода-год удалось восстановить матчасть (начали делать ТО и капремонты, закупать запчасти, заставили ремонтников поднять жопы с батареи и начать крутить гайки).

Хорошо, когда клиенты стоят в очереди и можно из них выбирать. Один умный человек говорил, что в этой ситуации нужно отсекать самых бедных и самых богатых клиентов - и у тех, и у других соотношение гемороя к прибыли очень плохое.
Но в сфере 1С обычно хватаются за всех заказчиков, деньги же. Даже за тех, кто будет убыточным с вероятностью 90% - позитивное мышление же, 10% - неплохие шансы!
35. glebushka 242 03.10.18 22:28 Сейчас в теме
(32) насчет сначала продумываем тема неплохо раскрыта вот в этой книге https://www.ozon.ru/context/detail/id/145743740/
38. DDA4746 04.10.18 10:11 Сейчас в теме
(35)
Спасибо, сделал закладочку на почитать.
36. glebushka 242 03.10.18 22:30 Сейчас в теме
(32) насчет сначала продумываем тема неплоха раскрыта тут: Building Evolutionary Architectures: Support Constant Change by Neal Ford, Rebecca Parsons and Patrick Kua. Если на русском, то можно найти перевод Building Microservices: Designing Fine-Grained Systems 1st Edition by Sam Newman там в общем-то тоже вся инфа есть.
31. Крококот 03.10.18 09:17 Сейчас в теме
(25) Благодарю за пояснения.
Типичная ситуация, но в "особо крупных размерах". Обычно проблемы, порождаемые схожими ситуациями, поменьше будут.
То, что водопад критичен к качеству обследования (и к квалификации сотрудников, его выполняющих) - факт. Полностью определить потребности клиента - фантастика, но "близко к тексту" сделать - возможно.
Подскажите, а все эти хитрые потребности были отображены в старой информационной системе клиента? И, если да, то анализировали ли эту систему при обследовании?
37. glebushka 242 03.10.18 23:07 Сейчас в теме
(31)
1. Ну тут как бы ситуация в том, что обследование делали ребята "по-дешевле". На свое счастье клиент где-то к концу обследования понял, что цена не единственный критерий, который имеет смысл рассматривать при выборе подрядчика. На самом деле, редкий случай. Для нас типовая ситуация когда мы внедряем систему уже после одной, двух, а, есть один случай, когда и трех попыток внедрения 1С:ERP2. К этому моменту клиент уже вдоволь "наэкономил". Имеет тысячи страниц внушительных ТЗ, и десятки тысяч строк кода. Одна беда - не работает почему-то. И клиент уже не хочет по-дешевле, а хочет чтобы работало. Причем здесь и сейчас. А не через полгода, когда, наконец, команда по счету n+1 хорошо подумает, и таки поможет запустить систему.
И что самое интересное, чаще всего предыдущие команды состоят отнюдь из патологических кретинов. Т.е. как обычно россыпь "среднестатистических" одинэсников и пара-тройка вполне адекватных и с головой на плечах. И даже бизнес заказчика понимающих, чаще даже лучше чем мы на момент начала наших работ (ну они там уже год паряться, а мы-то только вот пришли). Да и проблема в таких случаях чаще в клиенте. Я видел настолько крутых клиентов, которые запускали у себя систему руками таких бойцов, которым я не доверил картошку фри в макдональдс жарить, а тут систему запустили. Смотришь, и офигиваешь. От крутости заказчика (ну вернее конкретных его топ-менеджеров). Другое дело, сколько сил этих людей было потрачено, достойных лучшего применения.
2. А так да, была система. Правда, почему-то данные каждый отдел собирал в экселе. И дебиторка по данным коммерческого отдела одна, по данных бухгалтерии другая, у финансистов - третья. И, в принципе, в зависимости от целей можно было даже выбрать любую сумму, какая больше нравится. Ну и как работает СИСТЕМА не знают даже создатели. Ну вернее создателей уже не было. Есть n-е поколение прогеров, которые делают что им говорят. В итоге в системе более 800 отчетов. И это только те, о которых знают в прогеры УК. А какие отчеты ваяют прогеры на филиалах - знают только прогеры на филиалах. Вопрос - а какие используются смогли выяснить только после того, как убедили ИТ-отдел счетчик на кнопку формирования отчетов повесить, чтобы в разрезе пользователей и отчетов получили статистику использования за месяц. Получили под 100 отчетов. Это без стандартных бухгалтерских. Только оперативный учет. Даром что его зачем-то сделали на бухгалтерских проводках (и нет, это была не 1С, а другая система, работающая на очень древней магии). В итоге у нас получилось 5 отчетов по итогам внедрения системы.
А уж пояснить схэму проводок могли у клиента пояснить вообще все кого назначил заказчик в качестве "ключевых пользователей". Только количество пояснений было сильно больше, чем число опрошенных. Ну просто некоторых несколько раз переспрашивали, и сколько раз спрашивали - столько разных объяснений и получали. Ну и ближайшее рассмотрение показало, что система-то одна, но как бы распределенная, и "немножко" разная. Функций много, а какие используются - выясняли тем же способом, что и выше - вешаем счетчики. Это в дополнение к наблюдению за работой линейного персонала. Операторы пояснить вообще ничего не могут, но зато с радостью показывали что делают, а на вопросы почему для этого клиента другой документ используешь - отвечает, ну я уже 10 лет здесь работаю, и этому клиенту мы всегда этим документом отгружаем :)
В общем как-то так получилось, что систему всю и сразу "как есть" мы решили почему-то не описывать. Правда, клиент очень просил. Но мы предложили клиенту предыдущего подрядчика нанять, нехай опишет, уж очень у него красивые отчеты получаются. Главное, чтобы нас не отвлекали, и прикрепленных к проекту прогеров Заказчика.
mityushov.vv; zxcvb98765; DDA4746; +3 Ответить
33. katenok86 244 03.10.18 12:55 Сейчас в теме
(25)С переводами с одной 1с на другую все понятно. Это проходили. А вот со сторонних систем. Если я поняла вы сознательно в бюджет включаете разработку синхронизаций со старой системой? До момента полного перехода
34. glebushka 242 03.10.18 22:26 Сейчас в теме
41. s_vidyakin 16.11.18 12:21 Сейчас в теме
(25) Похожая фигня была на одном проекте, куча деталей выяснилось уже на нефтеперегонном заводе ) За границей. В конце внедрения. Пришлось впиливать с нуля блок учета результатов анализа нефти (АРМ лаборатории), учет взвешивания при наливе в грузовики, и еще много нюансов по производству и передаче по нефтепроводам из нескольких участков в разных странах... Весело было, заодно сербский язык выучил
4. katenok86 244 01.10.18 12:47 Сейчас в теме
А на этапе перехода с 1 на 3 например что делается с остатками по тмц и взаиморасчетам? которые ранее накопились? До окончания до 6 пункта учет дублируется в 2 -х программах? старой и новой?
6. acanta 01.10.18 12:53 Сейчас в теме
Да, конечно. В старой программе в это время ведутся работы по предшествующему периоду. Остатки по 1-2 пункту меняться не должны по определению.
Начиная с 3-го могут быть изменения, и их следует периодически обновлять. С тем, чтобы к моменту закрытия баланса в старой системе за предыдущий период остатки в аналитике по пункту 3 были синхронизированы.
А вообще чем отличается внедрение регл.учета по скрам в ЕРП от любого другого внедрения регл.учета?
8. katenok86 244 01.10.18 12:57 Сейчас в теме
(6)Тем что по скрам счета запускаются последовательно. А по водопаду мы запускаем с начала года и параллельно
9. acanta 01.10.18 13:14 Сейчас в теме
(8) В чем смысл ведения параллельного регламентированного учета с начала года в старой системе?
Точнее параллельно именно регламентированного, без оперативных данных вообще? На это Контур есть.
По счетам (51-50-70-68.НДФЛ-69)->(41-46-62-60)->(10-76-08-68.НДС)->(01-02)->(20-90-91) Обычный бизнес-процесс.
10. katenok86 244 01.10.18 14:58 Сейчас в теме
(9)то есть баланс вручную собирать? На больших объемах это очень трудоемко
11. katenok86 244 01.10.18 15:04 Сейчас в теме
(9)Контур просто система отправки отчетов она ни чего не консоледирует. У вас есть реальный опыт такого внедрения, на заводе например с численностью 1000 и свыше человек?
12. user633533_encantado 7 01.10.18 15:22 Сейчас в теме
Интересно было бы почитать, почему не взлетело с первого раза, что конкретно не получилось.
vipetrov2; Irwin; +2 Ответить
13. acanta 01.10.18 15:32 Сейчас в теме
(12) 1000 человек или рабочих мест 1С? У нас не получилось запустить оперативный контур ЕРП, поскольку начали с регламентированного учета и выведения баланса.
Предприятие с количеством раб.мест от 1000 такого опыта нет.
14. triviumfan 22 01.10.18 16:17 Сейчас в теме
Имхо это дурной клиент, а не спасение с помощью scrum.
ЗЫ: столько американизмов, что без словаря не понять.
Artem-B; Dmitri93; Mantis; +3 Ответить
15. acanta 01.10.18 16:37 Сейчас в теме
(14) Это не американизмы, это транслитерация.
(11) водопад это не метод, а порог вхождения. Если вы можете сделать проект по водопаду, то скрам точно сможете. А зачем клиенту внедренец, который чего-то не может?
Valerych; +1 Ответить
18. DDA4746 01.10.18 18:49 Сейчас в теме
(14) Вообще срок для такого масштаба эпичный - 3 месяца проектирование, 3 месяца разработка.. Фантастика на грани неадеквата, учитывая, сколько времени занимает согласование процессов с заказчиком (особенно нефтяным).
LordKim; zxcvb98765; Mantis; +3 Ответить
16. ISP 01.10.18 17:19 Сейчас в теме
не понял как помог scrum запустить систему ведь в начале было сказано, что проблема в заказчике. А Scrum использовался для управления командой
Mantis; Dream_kz; +2 Ответить
17. DDA4746 01.10.18 18:46 Сейчас в теме
(16) Очевидно же - коллеги начали управлять командой :)
Вообще, этот процесс реально сложно организовать и главное - поддерживать; к сожалению, многие РП даже в крупных компаниях этим не занимаются..
19. CheBurator 3426 01.10.18 23:02 Сейчас в теме
так осталось и непонятно, почему не взлетело по первому варианту.
Уделили много внимания блокам, но не уделили внимания связям и взаимодействиям?
поясните "ширшее"
Mantis; Dream_kz; +2 Ответить
20. sailor-cat 5 02.10.18 04:35 Сейчас в теме
Не так давно на собеседовании соискатель нас уверял, что «в 1С agile точно не работает, это невозможно». Самое забавное- дело было в Красноярске.
Написали бы раньше, было бы ещё забавнее)
21. vipetrov2 02.10.18 04:47 Сейчас в теме
Статья познавательная. Но в данном случаи результат был достигнут за счет психологического эффекта. У заказчика было слишком много оппонентов против внедрения, поэтому руководство не могло пойти на такой конфликт. А против такого постепенного внедрения у этих оппонентов не нашлись достойные аргументы. Здесь конечно команда отработала хорошо, хотя и пришлось тратить больше времени.
22. Крококот 02.10.18 06:00 Сейчас в теме
Поддержу высказавшихся выше: из статьи совершенно неясно по какой причине не смогли запуститься по "водопаду", если "все было сделано по ТЗ"? В ТЗ были закреплены неактуальные требования? Имел место саботаж со стороны персонала заказчика? Не было продумано взаимодействие между программными продуктами?
Также неясно что позволил сделать Scrum и не позволил "водопад" для того, чтобы проект все таки "взлетел"? Что нужно было сделать для этого? Была применена старая-добрая "доработка напильником по месту"?
С одной стороны очень интересная статья от компании, которая на практике использует Scrum. Большое спасибо, что поделились опытом.
С другой вопросов порождает уж слишком много, да и похоже, уж извините, на рекламу. "Мы раньше внедряли по водопаду как и все, но столкнулись с некой проблемой, применили Scrum и все стало прекрасно и хорошо. А кто хочет узнать как это на самом деле может попробовать занять место в нашей команде".
CheBurator; user633533_encantado; Kaspirovsky; +3 Ответить
23. WalterMort 322 02.10.18 11:01 Сейчас в теме
Стандартная ситуация, пока заказчик платит и "не смотрит" - пилим ересь, которая подходит под подписанные "требования". Вторым этапом, когда результат "на лицо" и заказчик уже не хочет платить за кота в мешке, начинаем "качать" его итерациями. Редкий проект проходит другим образом.
mityushov.vv; zxcvb98765; KapasMordorov; +3 Ответить
24. KontoraB 02.10.18 11:40 Сейчас в теме
Мда - что то сдается мне - команде внедренцев надо было работать на каждом рабочем месте заказчика вживую (настраивать показывать проверять по каждому работнику заказчика)- тогда бы и по классике б взлетело
Mantis; acanta; +2 Ответить
26. DDA4746 02.10.18 15:10 Сейчас в теме
(24) Вообще, это идеально (не только в 1С). Чтобы не получалось технически прекрасных систем, которыми никто не может (не хочет) пользоваться.
А иногда, тестируя какой-либо документ, очень хочется разработчика посадить за руль и заставить ввести пару сотен экземпляров его шедевра - исключительно в карательно-образовательных целях, чтобы осознали, что делать документы\отчеты\процессы нужно для людей, а не согласно ТЗ.
LordKim; Mantis; +2 Ответить
30. Mantis 136 03.10.18 08:05 Сейчас в теме
Ничего не понятно про первую часть , исходя из этого не вижу ни какого смысла читать вторую с кучей иностранных слов)
39. grinder 17 04.10.18 11:02 Сейчас в теме
40. mityushov.vv 179 19.10.18 16:22 Сейчас в теме
Самое важно это демонстрация выполненной работы еженедельно и заказчик видел что делается в системе постепенно вникал в вопрос и разработчики с консультантами начали проверять и тестировать то чт осами натворили в этом был залог успеха плотное взаимодействие с заказчиком. Ну и конечно немного свою работу правильно организовали в части взаимодействия в команде по Scrum.
Оставьте свое сообщение

См. также

Ошибки управленцев: как топ-менеджеров убивает перфекционизм Промо

Управление проектом Бесплатно (free)

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    9820    user809424    11    

Как стать исполнителем в проекте от Инфостарта

Управление командой Управление проектом Бесплатно (free)

Инфостарт в поисках специалистов, которые готовы взяться за реализацию интересных проектов. Как подать заявку и стать исполнителем, с кем согласна сотрудничать компания и на каких условиях, рассказал руководитель проектов корпоративного отдела Инфостарта Александр Блинов.

11.09.2020    2095    alexandr.blinov    17    

Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей

Управление проектом Бесплатно (free)

Ниже я попыталась собрать житейские советы от опытных руководителей проектов 1С и выпускников курсов по управлению ИТ-проектами на Инфостарте с моими комментариями. 

04.09.2020    2503    MariaTemchina    22    

Что делать, если с поддержкой 1С всё горит или несколько слов про ITSM…

Управление услугами и сервисом Управление бизнес-процессами (BPM) Управление прочее Управление проектом Бесплатно (free)

Проекты - это, конечно, важно, с завершением проекта внедрения, жизнь прикладного решения, на самом деле, только начинается. И самое интересное еще только впереди… Не случайно в Agile все чаще говорят о “гибком управлении продуктом”, а вовсе не только “проектом”.

20.08.2020    2352    MariaTemchina    4    

Проблемы внедрения 1С:ERP на крупном предприятии Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом реальных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию очередную статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

29.06.2017    34295    1СERP    79    

Управление в стиле Догвилль

О жизни Управление проектом Бесплатно (free)

Как и почему жизнь на работе становится всё хуже. Или всё лучше.

26.06.2020    4158    1c-intelligence    15    

Есть ли жизнь после внедрения, или упрощаем работу в сопровождении

Управление проектом Бесплатно (free)

Из-за отсутствия грамотных правил разработки на этапе внедрения сильно усложняется работа по поддержке и развитию типовых доработанных конфигураций. О некоторых правилах и подходах в разработке, которые помогут специалистам сопровождать внедренное решение, на конференции Infostart Event 2019 Inception рассказал разработчик компании «Инвестиционная группа Абсолют» Алексей Степаненко.

08.06.2020    4714    stepan96    12    

Добрый великан

Управление проектом Бесплатно (free)

Руководители проектов определяют наше настоящее, каким оно будет?! Ответ прост - таким, каким и сам РП.

25.05.2020    5296    sapervodichka    1    

История одного неуспешного проекта Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом неуспешных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию первую статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

09.06.2017    31023    1СERP    175    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    10617    MariaTemchina    33    

Кто здесь? Или как проводить онлайн-совещания

Управление проектом Управление командой Бесплатно (free)

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

23.03.2020    5529    MariaTemchina    24    

4 причины, почему проекты никогда не завершаются в срок

Управление проектом Бесплатно (free)

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

03.03.2020    6120    VLikhobabin    44    

Такие разные франчайзи. Часть вторая: Особенности реализации крупных проектов, Глава 1. О людях Промо

Управление проектом Бесплатно (free)

Продолжаем публикацию цикла статей о бизнесе франчайзи 1С. В предыдущих статьях мы рассказали о наиболее распространенном мнении о фирмах франчайзи 1С, об истории развития франчайзинга. Поставили вопрос о выборе системы мотивации. Предыдущие публикации вызвали оживленное обсуждение. В продолжении темы расскажем о том – как выглядит работа проектного подразделения фирмы-франчайзи. Расскажем на примере проектного офиса ВЦ «Раздолье». Предложим обсудить проблемы, с которыми приходится сталкиваться в проектном бизнесе. Автор статьи Андрей Мироненко.

18.04.2017    31906    1СERP    189    

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

Управление проектом Waterflow Бесплатно (free)

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

23.01.2020    13879    MariaTemchina    8    

1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

СППР Управление проектом Бесплатно (free)

Система проектирования прикладных решений (СППР) – инструмент от фирмы «1С», который позволяет проектировать конфигурации, вести по ним полную документацию в разрезе объектов системы, собирать требования на реализацию и выдавать на их основе детально описанные задачи программистам. Как правильно использовать СППР при работе с многосоставной командой, на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «Иритум» Роман Кальмансон.

09.01.2020    6567    roman72    0    

Про одну Тётю

Управление проектом Бесплатно (free)

Суровое челябинское распределение ресурсов

24.12.2019    6656    1c-intelligence    32    

Такие разные франчайзи, или как мы делаем большие проекты на 1С. Часть первая: ты помнишь, как всё начиналось Промо

Управление проектом Бесплатно (free)

Недавно была написана статья о том, как работает мотивация персонала. Материал получил активный отклик у читателей Инфостарта, на форуме развернулась дискуссия, которая в итоге была достаточно далека от содержимого исходной статьи и свелась к критике самой идеи работы во франчайзи. Чтобы как-то ответить на эту критику, хотелось бы более подробно рассказать о том, что такое современный франчайзи и как он устроен. Но начнем мы с истории этого вида бизнеса, глазами рядового специалиста. Автор статьи Андрей Мироненко.

10.04.2017    31914    1СERP    107    

20 мыслей об ИТ-проектах. Мысль №3. "О правильных требованиях к системе"

Управление проектом Бесплатно (free)

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

14.10.2019    5949    chavalah    16    

Незакрытый проект на 1000 часов

Управление проектом Россия Бесплатно (free)

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    12215    ogroup    163    

Стратегия выживания в корпоративных войнах

Управление проектом Бесплатно (free)

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

16.09.2019    9621    GSoft    15    

Мотивация персонала в фирмах франчайзи: а она работает? Промо

Управление проектом Бесплатно (free)

Думаем, что практически любого работающего человека интересует вопрос мотивации. Этой проблемой в одинаковой степени озабочены работники и работодатели: как мотивировать людей, сколько платить, как платить, какая часть оплаты должна быть фиксированной, а какая зависеть от результата работы, как это всё повлияет на результаты работы, стоит ли быть строгим и дотошным руководителем или нужно активно делегировать полномочия подчиненным. ВЦ "Раздолье" провело небольшое исследование на тему мотивации и вот его результат. Автор статьи Андрей Мироненко.

03.04.2017    42650    1СERP    231    

Мастер-класс СППР

Управление проектом СППР Бесплатно (free)

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    11893    SergeyN    7    

Эволюция пользовательской документации 1С в производственной компании

Пользователю системы Управление проектом Бесплатно (free)

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

20.08.2019    8775    Arsen1986    7    

Быстрый старт: минимальный набор автоматизации типовых процессов

Управление проектом 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

16.08.2019    8287    Hissin    18    

Про спагетти, или как исследовать бизнес-процессы организации Промо

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

23.02.2017    27569    Gavrik    10    

Управление проектами по автоматизации бюджетирования

Управление проектом Финансовый учет и бюджетирование (FRP) Финансовый учет и бюджетирование (FRP) УУ Бесплатно (free)

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    8005    SergeyN    1    

Внедрение решений: как выполнять все обязательства в срок в условиях ограниченных ресурсов

Управление проектом Бесплатно (free)

Многие менеджеры вынуждены работать в условиях многоклиентской среды с ограниченными ресурсами. И вовремя сдавать проекты в таких условиях сложно. Как добиться того, чтобы поставки делались без нарушений сроков, рассказал гостям и участникам конференции Infostart Event 2018 управляющий партнер BIPULSE.RU Алексей Васильев.

24.06.2019    6748    sbase    9    

Цифровая трансформация. Будущее учетных систем

Управление проектом Россия Бесплатно (free)

О цифровой трансформации слышали все, но немногие в этом разбираются. Что она собой представляет, какие несет изменения, на что надо обратить внимание айтишникам и 1С-никам, рассказал на конференции руководитель департамента автоматизации строительных организаций компании «Первый БИТ» Иван Аверьянов.

19.06.2019    10205    FB_10160810658600104    62    

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

Управление проектом Бесплатно (free)

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

17.06.2016    40132    raiml    37    

Риск - благородное дело!.. Часть первая

Управление проектом Бесплатно (free)

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    7554    MariaTemchina    8    

Мы в ответе за то, чего вовремя не послали. Матрица ответственности в проектах внедрения

Управление проектом Бесплатно (free)

В своей публикации “Устав писать Устав” я много рассуждала о том, как полезно умение договариваться на берегу. Как известно, у каждого человека в голове своя картина мира. В целом, многие конфликты в ходе проектов происходят как раз из-за конфликта ожиданий, и из-за нечетких договоренностей, кто чем должен заниматься.  

31.05.2019    9044    MariaTemchina    23    

Как мы со Стасом завод за 2 месяца автоматизировали

Управление проектом Бесплатно (free)

Мой опыт быстрого внедрения.

14.05.2019    11167    1c-intelligence    121    

Практические вопросы внедрения и развития автоматизации склада Промо

Управление проектом Бесплатно (free)

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

26.12.2014    44641    CheBurator    64    

Устав писать Устав

Управление проектом Бесплатно (free)

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    7563    MariaTemchina    8    

Как сжать время?

Управление проектом Личная эффективность 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Как, и зачем измерять задачи в чем-то, помимо часов.

04.05.2019    8965    1c-intelligence    39    

Путь джедая в управлении проектами 1С: умение быть, а не казаться

Управление проектом Бесплатно (free)

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

15.04.2019    11684    MariaTemchina    15    

Практика пуска склада продуктов питания Промо

Бухгалтерский учет Управление проектом Оптовая торговля, дистрибуция, логистика 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описывается опыт пуска склада (охлажденная и замороженная продукция) с точки зрения IT. Со временем из складского подразделения была создана компания, которая оказывает логистические услуги (3PL-оператор) сторонним Клиентам.

1 стартмани

14.09.2015    36266    axxell    15    

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?"

Управление проектом Бесплатно (free)

Продолжаем серию статей из цикла “20 мыслей об ИТ-проектах”. Сегодня мы поговорим о том, с какой стороны подойти к новому проекту. Такой вопрос возникал у каждого, кому приходилось выступать в роли руководителя проектов, особенно первый раз. Да и для опытных РП некоторые проекты вызывают аналогичный вопрос.

13.02.2019    8231    chavalah    22    

Стыд и скрам - Чему нас учит Scream Guide

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    10001    MariaTemchina    20    

Бизнес, не горюй

Управление проектом Бесплатно (free)

Про цели автоматизации.

04.02.2019    10081    1c-intelligence    64    

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

06.04.2015    37743    raiml    14    

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

Управление проектом Бесплатно (free)

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

31.01.2019    8329    MariaTemchina    0    

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан

Управление проектом Бесплатно (free)

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

14.01.2019    10137    MariaTemchina    13    

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях"

Управление проектом Бесплатно (free)

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

10.01.2019    12843    chavalah    123    

Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть II Промо

Управление проектом Бесплатно (free)

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

16.11.2014    28770    raiml    46    

Где мы взяли флакон?

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

История появления и развития методики

26.12.2018    9843    1c-intelligence    7    

Озарение после прочтения макулатуры по проектному управлению

Управление проектом Бесплатно (free)

Открываю этой публикацией мини-рубрику "Письма в редакцию". По мотивам очередной статьи на Инфостарте пришло мне письмо на корпоративную почту. Прямо-таки, крик души. С разрешения автора, решила опубликовать публичный ответ. Ибо согласна с автором письма, пишущим: "Я уверен, что не я один такой убогий, кто задается подобного рода "идиотскими" вопросами, но при этом почему-то все молчат, видимо, pmbok с agile-ом поистине творят чудеса молчания..."

19.12.2018    9819    MariaTemchina    24    

20 мыслей об ИТ-проектах, или 20 лет спустя.

Управление проектом Бесплатно (free)

В этой серии из 20-ти статей я готов поделиться своей практикой управления проектами. Примеры, опыт и только то, что проверено лично. Выбираем темы голосованием!

09.12.2018    9180    chavalah    119    

Бизнес-консультант в малом и среднем-бизнесе. Кто это и зачем он нужен? Промо

Управление проектом УУ Бесплатно (free)

Я не буду здесь давать сухие определения, думаю, они никому не интересны. Бизнес-консультант – это тот самый человек, которого приглашают со стороны, чтобы он помог найти решение каких-то проблем. Также очевидно, что взгляд «со стороны» очень часто помогает выявить то, что вы никогда не обнаружите, будучи сотрудником компании. Я хочу с вами поговорить исключительно о бизнес-консультантах, которые работают с малым и средним бизнесом, т.к. с предприятиями с численностью сотрудников ориентировочно от 5 до 70 человек. Эта работа во многом отличается от того, что делают специалисты, которых привлекают в подобных случаях крупные компании. И, как раз, с этими нюансами есть смысл разобраться.

13.11.2014    27971    raiml    236    

Памятка руководителя: не играйте с деньгами

Управление проектом Личная эффективность Управление персоналом (HRM) Бесплатно (free)

Важная статья о персонале из цикла «Памятка руководителя»: здесь я планирую затронуть один из наиболее острых вопросов – деньги. А также развернуто ответить на некоторые комментарий читателей по двум прошлым статьям.

05.12.2018    17062    andironenko    128    

Шаг назад и ... шаг назад (классификация внутренних проектов)

Управление проектом Бесплатно (free)

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

03.12.2018    8716    capitan    26    

Белая и пушистая рецензия на Чёрную книгу Скрам

Управление проектом Бесплатно (free)

Данный текст является ответом на "Черную книгу Скрам" Ивана Селиховкина. Честно скажу, несмотря на то, что рукопись вряд ли предназначалась моему взору, прочитала ее на одном дыхании.  Публикую рецензию как есть - свое имя автор, к сожалению, не написал.

26.11.2018    10151    MariaTemchina    40