Писать о провальных проектах всегда не просто. Особенно, когда надо честно проанализировать причину, а не просто показать на кого-нибудь пальцем.
С точки зрения традиционных подходов проект успешный, если он закончился в срок и в рамках отведенного бюджета. Но я бы сюда еще добавила удовлетворенность заказчика, потому что в нашем бизнесе просто подписать акты недостаточно. Хотелось бы, чтобы клиенты отзывались о компании положительно, и, в идеале, принимали референсы.
В данной статье я попытаюсь проанализировать факторы, приведшие к проблемам на одном проекте, и дам оценку тому, как я бы поступила в данной ситуации сейчас.
Итак, о проекте. Компания занималась производством и реализацией сувенирной продукции (под «производством» у них понималась только нанесение логотипов и надписей на закупленную «сувенирку»). Клиент работал на сильно переписанной 7.7 (кажется, изначально это была «Торговля и склад», но за несколько лет активной кастомизации от типовой конфигурации ничего не осталось). Доработка велась собственной ИТ-службой, двумя действительно хорошими программистами. К моменту, когда мы зашли на проект, они уже прошли курсы по 8ке и были готовы влиться в проектную команду.
Основной причиной перехода было постепенное «умирание» базы из-за объема: она занимала под сотню Гб (тут могу ошибаться), и еще имела несколько распределенных узлов: документы еле «ползали», стоимость материалов уже не считалась. А бизнес расширялся, и собственники опасались, что еще одного года база не переживет.
Хотя речь шла только об управленческом учете, окно для перехода в новую конфигурацию было очень коротким – два месяца: апрель-май. В остальное время шла закупочная компания и подготовка к массовой новогодней корпоративной «сувенирке» — основному доходу Заказчика.
В старой базе предприятие вело только торговый учет (включая логистику, CRM и т.д.), в новой они дополнительно хотели видеть реальную себестоимость заказов (с учетом производственных операций) и бюджетирование.
В то время требование: торговля + себестоимость + бюджетирование — означали УПП. Тем более, что мы в то время специализировались в основном на внедрении данного программного продукта.
Первую фазу внедрения – проработку Функциональной модели — мы начали в мае-июне. Уже сразу стало понятно, что программный продукт в части торгового блока не подходит им на 90%. У них было отдельно ведение клиентов и партнёров, деление номенклатуры на сегменты с разным ценообразованием для разных категорий покупателей. Были справочные адресные склады и подписки клиентов на события. И еще много чего, что в то время уже было частично реализовано в УТ11.
Наверное, сейчас бы я вовремя рассмотрела варианты с другими конфигурациями. Точнее, предоставила бы заказчику всю информацию, в том числе предложила запустить второе параллельное моделирование процессов на УТ 11. Да, это стоило бы им дополнительных денег, но позволило бы принять более осмысленное решение и, возможно, снизило бы риски внедрения. Не знаю, куда бы вывернул проект в таком случае (на нем хватало и других проблем). Но с тех пор я стараюсь, во-первых, во время признавать свои ошибки. А, во-вторых, вовлекать в процесс принятия решений руководство заказчика.
ФМ на УПП шел очень тяжело. Пользователи не видели нужного им функционала, и буквально все приходилось объяснять друг другу «на пальцах». В итоге концепт мы все-таки защитили, но он предполагал почти 200 доработок объемом под 4 тысячи человеко-часов. Бюджета на такое дело у них не было, так что от половины (!!!) доработок было решено отказаться, а оставшуюся часть поделить пополам с их ИТ-службой.
Даже объем в 1 тысячу часов кодирования мы на тот момент еще ни разу не «поднимали». Это сейчас уже понятно, зачем нужны интеграционные тесты, формализация требований к общим справочникам и так далее. Но в то время я просто решила набрать на проект побольше программистов (некоторые «выжившие» вспоминают то кодирование до сих пор).
На этапе разработки технических заданий руководство клиента решило, что согласовывать их будет именно ИТ-служба, а не конечные пользователи. Сейчас мы больше на такое не соглашаемся. Ставить задачу должны те люди, которые потом будут принимать систему. Но в то время это показалось хорошей идеей: два «технаря» по идее должны были быстрее договориться по поводу требований к функционалу.
Для проекта это было фатальной ошибкой: ИТ-служба ставила нам задачу так, как они понимали ее сами: с технической стороны, а не с точки зрения процесса. К тому же, как показал запуск, очень много моментов, которые они считали неважными, были упущены. Также люди, которые кодировали доработки 10 лет назад, уже просто частично подзабыли, как именно они должны были функционировать.
Все это «вылезло» на этапе первого контакта системы с реальными пользователями, и привело к 400м часов запросов на изменение (то есть почти 50% от нашего объема доработок). Примерно столько же «прилетело» и на ИТ-службу, что, конечно же, не улучшило наших отношений.
Но сначала, до нашего эпического «первоначального обучения ключевых пользователей» разразился кризис в самом кодировании: программисты мешали друг другу; в одни и те же справочники добавлялись одинаковые по смыслу реквизиты с разными названиями; накатывание одних доработок приводило к неработоспособности других. Причем, найти виновных было невозможно, потому что каждый кодировал свой кусок («к пуговицам вопросы есть?»).
Уже гораздо позже, по результатам полученного (через кровавые слезы) опыта у нас в фирме родился документ «Стандарты кодирования», в котором мы описали (и актуализируем до сих пор) основные принципы разработки.
Глобально с того проекта я вынесла правило «учись на чужих ошибках»: если ты чего-то не делал на проекте раньше, то сядь и подумай, что может пойти не так; поспрашивай народ на форумах, почитай переписку, литературу и так далее – в нашем бизнесе сложно придумать что-то действительно новое, чего раньше никто не делал.
Но в то время мы просто «бились головой о стену», съедая отпущенные на разработку часы и время. Своих проблем добавила и платформа, в которой от версии к версии хранилище работало все хуже и хуже: куски кода пропадали целыми блоками, уже протестированные доработки переставали работать; некоторые вещи пришлось реализовывать по нескольку раз. С тех пор мы с очень большой настороженностью относимся к любым обновлениям платформы в ходе проекта.
Разработку мы должны были закончить в январе, чего, конечно же, сделать не успели. Февраль-март ушли на доведение системы до ума и на интеграцию с доработками, которые сделала к тому времени ИТ-служба заказчика, наступавшая на те же грабли.
А в апреле мы совместно пошли сдавать систему ключевым пользователям, и это было мероприятие в стиле «я кинул атомную бомбу, и она жахнула…». Начались истерики, швыряния документов и бесконечные совещания.
Спасло меня в тот момент только наличие подписанных технических заданий (всегда прикрывай «пятую точку» бумажкой, ибо никто не знает, когда что выстрелит). Заказчик скрипел зубами, но платил за переработку. Правда, его лояльность быстро упала «ниже плинтуса».
Сейчас мы, конечно, уже так не работаем. За 15 лет работы в этом бизнесе я еще не встретила заказчика, который может на этапе ФМ или даже ТЗ полностью осмыслить будущее поведение системы. Все равно на этапе эксплуатации вылезают вещи, которые надо подправлять. В определенный момент я приняла этот факт как данность, и теперь просто закладываю в стоимость доработок примерно 20% на их «допиливание» на ходу. Клиенту проще один раз пережить большой бюджет, чем каждую неделю бегать к собственнику с допниками.
Также в ОПЭ я закладываю время на работу программиста: просто на отчеты или печатные формы, про которые все забыли на этапе ФМ, и прочие «бантики».
Нужно ли в таких условиях согласовывать ТЗ? Да, нужно, потому что с ним можно в любой момент остановиться, отметая откровенную «ересь».
На проекте с запросами на изменение мы провозились до середины мая. Дальше сдвигаться возможности уже не было, окошко «закрывалось». Приняли решение стартовать 20го мая, не смотря ни на что.
В первый же день прилетела вторая «атомная бомба»: как оказалось, выделенные в апреле ключевые пользователи тоже не владели полной информацией: были люди (а иногда и целые отделы), которые работали «чуть-чуть по-другому». GoLive Tracking рос как снежный ком, и в нем было 2 статуса: «исправить до завтра» и «исправить немедленно». Программисты (и наши, и их) работали по 14 часов в сутки, поедая часы на ОПЭ с экстремальной скоростью. В итоге заказчик «забил» на бюджетирование и «забил» на себестоимость. Весь бюджет был перенаправлен на доведение системы хоть до какого-то приемлемого состояния.
После 6-ти недель экстремального кодирования, часы закончились, и выделять на проект еще денег собственник уже был не готов. Довнедрение системы было поручено ИТ-службе, в итоге они ее постепенно довели до ума, и работают на ней до сих пор.
Акты нам подписали, но ни о каком положительном отзыве не могло быть и речи. Общий перерасход часов по всем работам составил 30%. Реальный перерасход – больше 50%.
Наверное, именно с этого проекта у меня и началась ломка сознания: изначально я выросла из программистов, потом перешла в консультанты, потом стала РП, но управление проектом воспринималась как побочная деятельность – ты, типа, берешь себе самый сложный блок, общую архитектуру, и заодно еще распределяешь между консультантами некий список задач.
На самом деле это плохо работает. При таком раскладе на одной чаше весов находится понятная, увлекательная и ощутимая работа по внедрению, а с другой – некая деятельность, которая в лоб не дает никакого прямого результата. Ну, ты один раз напишешь формальный «реестр рисков», второй раз, проведешь совещание с заказчиком по «статусу проекта». А потом на проекте постепенно начнут накапливаться вопросы, которые требуют перепроектирования, перекодирования и так далее. Ты все время что-то разруливаешь и перекодируешь, и все время занят. Ты уверен, что затягивание сроков и рост бюджета происходят по объективным причинам – ты же пропускаешь все решения через себя, и видишь, что заказчик со своей стороны не очень-то хочет что-то делать, консультанты «косячат», программисты выдают «г..нокод» и т.д.
Здесь надо себя просто переломить: основная функция РП – это двигать проект в нужном направлении и с нужной скоростью. Под «двигать» я имею в виду как своих спецов, так и Заказчика (то, что его сотрудники не горят желанием взваливать на себя доп.работу нормально – им за это редко доплачивают). В некоторых книгах по управлению проектам пишут, что РП на проекте вообще должен управлять только рисками: то есть постоянно прогнозировать (самому и с помощью проектной команды), что именно на проекте может пойти не так. И, самое главное, увидеть, что процесс где-то затормозился, объективно оценить причину и во время среагировать, чтобы не попасть в пресловутую ловушку «98-ми процентов».
В провале проекта почти всегда виноват именно его менеджер – в какой-то момент приходится это принять и начать работать над собой.
Закончить хочу словами Джо Мараско (за точность цитаты не ручаюсь): «проекты похожи на восхождение альпинистов – трудно планировать, важна слаженность команды и природа по определению сильнее тебя. Однако есть альпинисты, которые водят группы успешнее других».
Предыдующие публикации на тему управления проектами:
- Мотивация персонала //infostart.ru/public/605716/
- Как всё начиналось //infostart.ru/public/608547/
- Проектная команда //infostart.ru/public/612086/
- Проектная технология при внедрении 1С:ERP //infostart.ru/public/614725/
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Интересная статья. «Также в ОПЭ я закладываю время на работу программиста: просто на отчеты или печатные формы, про которые все забыли на этапе ФМ, и прочие «бантики».» — какие бантики?
(1)
удобная справка по состоянию заказов, печать счета из заказа, загрузка прямо в документ из ёкселя и туча других плюшек, что щедро раскиданы по старой системе, о которых никто не вспоминает до момента ввода новой системы в эксплуатацию…
Такие статьи на порядок полезнее успешных внедрений.
Беда в том, что пытаетесь воспроизвести то что было — зачем?
Используя типовой механизм, надо оптимизировать бизнес процессы клиента под них, а уж потом кодировка. Или смена типовой.
Начинать надо с бизнес процесса компании, а не то что было. В результате хотелок менеджеров приводится конфигурация к дому без фундамента. Просто не представляю зачем переписывать на 90%. Тогда уж ТЗ подробное и с 0 строго по ТЗ, а хотелки неучтенные, после сдачи проекта хоть годами дорабатывать. Чума а не внедрение у Вас было.
Как это все знакомо. Видимо, каждый франч должен пройти через такой проект…
Как все знакомо
Какое ТЗ пилить?
Подробное? На больших да и не очень проектах когда заказчик хочет точно знать что он получит и за что платит деньги — нереально составить ТЗ которое описывает готовый результат да ещё с такой степенью подробности — на одно составление такого тз уйдёт куча времени и денег. Составляя подробное тз ты сталкиваешься с задачами заказчика которые лежат на стыках подразделений — начинается либо тупняк либо отпихиваете и тихое подсылание нафиг со стороны заказчика. Вынесение таких вопросов наверх либо существенно тормозит процесс тз либо вопросы решаются командирским решением руководителей заказчика и такие решения частенько полумертвые
Писать тз на уровне функциональных требований — всегда есть разногласия причём существенные как кто эти требования понимает.
И все становится непонятно…
Все прочитал с большим интересом.
Спасибо за цитату Джо Мараско, очень понравилась.
(4)
Может, потому что речь об УПП? Мне очень знакомо подобное внедрение, успешное правда, с самописки на базе 7.7 на УПП с доработками, правда, в другой отрасли(пищепром — производство + оптовая торговля + логистика, полный цикл). На типовой УПП уже бы на 2-й день все либо встало, либо как то работало с неимоверными усилиями сотрудников, которые уже на 2-й день устроили бы бунт, т.к. работать круглосуточно не может никто. Элементарный цикл: прием заказов — резервирование и оформление — планирование логистики — отбор и доставка по клиентам, уже на этапе логистики бы столкнулся с трудностями, т.к. фактически этого функционала в УПП нет. Ну допустим в Excel-е логисты все сделали, дальше у склада увлекательная задача — разложить все по машинам «по бумажкам» (распечатанным Торг-12). Плюсуем человеческий фактор — и доставка фактически либо сорвана, либо осуществляется с существенным опозданием. На след. день руководство дает всем по шапке и внедрение откатывается.
Очень длинно написал, простите.
Но вижу по другим обсуждениям здесь, что проблема ключевая. С поправкой — кто организует проект. Если такая структура, как «Раздолье», то бюджет большой.
Многие не тянут. Я смотрю, что все у меня идет только когда крупный проект заказчик мощно тянет сам. Есть прекрасные случаи взаимодействия, но много повисает в круге описанных проблем.
Может есть способы мало затратной интеграции подрядчиков?
(10) Проблема в том, что * получает руководство, а проблемы — ИТ служба. Понятно, что иногда у ИТ не выдерживают нервы 🙂
(11) Фигассе, тут цензура чтоле? ***
Всегда с клиентом обговариваю докручиваем типовой до ваших хотелок с минимальными изменениями, на с соглашениями, что всякие изменения типового обсуждается точно. Если сохранение типовой не важно, тогда свобода полная, но чтобы программист внес доп. поле не проанализировав что уже есть — это делитанство. Адекватный ИТ отдел кстати по моему опыту наоборот является аккумулятором хотелок и отсекает дурные идеи, что занимает много времени внедренца если он будет слушать эту чушь. Про ТЗ да сложно, да кропотливо, но на большой проект необходимость, иначе не оплата или неудовлетворенность клиента (меня развели на бабки)..
Не понятно, почему вы вообще навязали клиенту УПП, ведь прекрасно понимали, что придется переписывать? Может из правила «втюхать, а потом хоть пожар»?
(1) справочная информация и вовсе забывается (в т.ч. инструкции для конечных пользователей).
Сотрудники меняются и начинается бегство к программерам с вопросами «а куда дальше нажимать» или «ЧЯСНТ» (что я сделал не так).
У нас в фирме было так (у многих так).
хорошая статья, спасибо. Еще понравились иллюстрации, как раз в тему. Пора по 1С сделать аналогичные 🙂
О как! По жизни, я так понимаю, если бы 20% бюджета заплатили упомянутым двум толковым сотрудникам ИТ, проект был бы не провальным, а вполне себе успешным. Это, собственно, иллюстрация к моему несостоявшемуся докладу на конференции Инфостарта. Причина провальных проектов (ну, процентов на 60) — привлечение «профессиональных» внедренцев.
Классика. 50 лет назад было известно, что добавление программистов удлинняет процесс программирования. А теперь вдруг это опять открывают…
Респект автору за честность.
. Кому принадлежит проект?
Ошибка:
Природа проектов изменчива, а изменения часто встречают сопротивления. Большинству не нравятся изменения, поэтому люди хотят знать, что они необходимы и принесут пользу. Для модификации проекта необходима поддержка высшего руководства, иначе он будет развиваться очень медленно. Проект — это процесс изменений, а топ-менеджер – это человек, который способствует его развитию. Без поддержки высшего руководства компании реализация проекта будет очень напряженной.
Решение:
Убедитесь, что у вас есть поддержка высшего руководства. Должна быть прямая связь между топ-менеджерами компании и акционерами вашего бизнеса. Ключевое сообщение должно быть таким: «это произойдет, так что вы либо с нами, либо без нас» и убедитесь, что они не выберут второй вариант.
Как менеджер проекта, будьте внимательными, чтобы топ-менеджер не принял управление проектом на себя и не стал фактически руководителем проекта.
2. Привлекайте пользователей
Ошибка:
Отсутствие вводимой пользователями информации и недостаток их вовлеченности– рецепт для плохого проекта. Такая ситуация может быть вызвана образом мышления ИТ-департаментов: «мы знаем, что вам нужно», или недостатком интереса со стороны пользователей. В любом случае, такой ситуации следует избегать.
Решение:
ИТ-департаменту нужно время чтобы понять требования клиентов прежде чем предлагать любое техническое решение. Часто ИТ-департаменты ослеплены последними, самыми новыми информационными продуктами и стараются подогнать существующие требования под них. С другой стороны, для успешной реализации проекта клиенты должны выделить некоторое время и совместно с ИТ-отделом убедится, что все их требования были полностью обозначены. Удостоверьтесь в том, что вы поговорили со всеми акционерами компании и учли их требования, и в том, что они поддержат Вас на протяжении всего проекта.
Остановите расползание масштабов проекта
Ошибка:
Увеличение масштаба проекта – одна из основных причин неудач. Не знание точных итоговых целей проекта или потворство своим порывам энтузиазма – рецепт неудачного проекта.
Решение:
Убедитесь, что бизнес-план, требования и рамки проекта четко определены и задокументированы. Акционеры компании поняли их и поставили на них свою подпись. Жестко придерживайтесь установленного объема проекта и, если необходимо внести изменения, проведите их через процесс управления изменениями, где они будут задокументированы, будет подтверждена их правомерность и они будут утверждены.
(0) Картинки я бы убрал, отвлекают
(17) Арчи, собственники удавятся, но своему персоналу — лям не заплатят. заплатят на сторону.
(1)
Спасибо. В дискуссиях в предыдущих статья коллеги просили поделиться опытом реальных не особо успешных проектов. Эта статья — первый такой опыт
(3)
Спасибо. Передам автору.
(4)
Вы, конечно, правы.
Только «на берегу» было ограничение:
Предыдущая система, вцелом, устраивала Заказчика. Причина перехода — преимущественно, технологическая. Поэтому клиент не особо был настроен на «оптимизацию бизнеспроцессов». Поэтому и основными заказчиками оказалась ИТ-служба, а не бизнес.
Больше мы на такое «не ведемся».
(14)
Цитата из статьи: «торговля + себестоимость + бюджетирование — означали УПП»
(17)
«О как! По жизни, я так понимаю, если бы 20% бюджета заплатили упомянутым двум толковым сотрудникам ИТ, проект был бы не провальным, а вполне себе успешным. Это, собственно, иллюстрация к моему несостоявшемуся докладу на конференции Инфостарта. Причина провальных проектов (ну, процентов на 60) — привлечение «профессиональных» внедренцев.»
— Не был бы. Переходить нужно было быстро, двумя людьми это сделать было невозможно.
«Классика. библия 50 лет назад было известно, что добавление программистов удлинняет процесс программирования. А теперь вдруг это опять открывают…
Респект автору за честность.»
— Все читают теорию, но осознавать и использовать начинают после своих шишек. Об этом и пишет автор.
(18)
В данном проекте один из собственников бизнеса — был куратором проекта и активно в нем участвовал.
(19)
согласен
(20)
Так одной из ключевых проблем этого проекта было то, что границы определила ИТ-служба. Границы были. Позже оказалось, что то, что получалось «в границах» бизнесу было не нужно.
(21)
Выше был положительный отзыв о картинках. Так что пока 1:1
Это классика внедрения, при опросе руководителей и исполнителей, какие функции выполняют исполнители, списки функций не совпадают 🙂
Как часто такое приходиться встречать.Хуже наверное только бывает,когда твой руководитель согласовывает то,что сам не понимает.Или оценку делает.Или когда желания клиента многократно превосходит его финансовые возможности.А сейчас стало модно играть конкурсы.Где ТЗ от клиента его желаний это бред сумасшедшего. Или проще,копирование описаний конфигураций с сайта 1с.А когда выигрываешь.Начинаешь разбираться,а оказывается нужно совсем другое.И намного дороже.Клиент в 99% сам не знает до конца,что он хочет.И после такого работать не хочется.Чувствуешь себя идиотом.Что скажешь «что в ТЗ то и сделаю?».После этого тебе точно спасибо не скажут.Порой,что бы что то внедрить уходит несколько недель понятия учета и принципа работы организации.В этом плане работы по 1с по мне так очень сильно спешат.Всегда очень маленькие сроки.После последней оценки переноса из сторонней программы в 1с моим руководителем при которой я пол месяца проработал бесплатно.Спасая честь нашей организация.Потому что он ее даже не открыл.Я ушел.Честно говоря,учет и программы становятся сложнее и работы,которые требуются от компаний франч стали дороже.Сейчас проще держать своего под боком.Сидел бы он в организации и пилил бы код.А не бежал бы после обеда ко второму клиенту.Статья действительно полезная.Приятно понимать,что не только ты один в таком бывал.Самое главное опыт чужой.Лишний раз убеждаешься.Что перед работой,нужно пройтись по всем пунктам,людям и задачам.Так что спасибо!
Фига провальный проект 🙂
Единственный провал — отсутствие хорошего отзыва 🙂
Клиент все оплатил, включая переработки => прибыль получена. Для раздолья проект успешный, УПП втюхано, доход получен. Если бы было озвучено, что мы отработали 2000 часов, а нам заплатили за 1000, то да, грусть тоска.
(32) увы, зачастую даже то что «говорят» исполнители и то что они «делают» на самом деле, тоже не совпадает. На моей практике они «забывают» о чем-то сообщить, нередко это ключевая их функция с точки зрения автоматизации.
(32)Согласен, на практике была ситуация, когда неделю прописывали схемы процессов с руководством, а потом пришел работник, который будет работать с этой системой. И сказал, что он физически не успеет всё делать, потому что при текущей нагрузке он выдает печатные документы работникам в течение двух часов (а надо за полчаса), а при доработке количество кликов увеличивается больше чем в два раза.
(36)Требуйте подписания ТЗ не только руководителями, но и участниками рабочих групп. Когда будущие пользователи видят, что под документом будет стоять ИХ подпись, сразу же начинают вспоминать больше, начинают вчитываться в ТЗ и давать комментарии (и количество неучтенных моментов сильно уменьшается).
(22) Кстати да, руководителю департамента-заказчика, или ИТ-службы, всегда в разы проще выбить большой бюджет на подрядчика, чем на небольшое увеличение ФОТ для внутренних исполнителей. Много раз сталкивался с этим
(17)
В статье описано, что ИТ — отдел молотил на 100500 процентов. Не помогло.
«Профессиональных» — имеется в виду, тех что соглашается по всем позициям с заказчиком и тонет в компромиссах? Или не выполняет обязательства? На что намек?
Что проект с ERP скорее всего не случиться, если привлечь кого-то со стороны? Это не так.
(36) Согласен, опрос это только первый этап. Потом еще и собственное исследование бизнес- процессов нужно делать.
(35)
Ну… перерасход бюджета там был приличный. Клиент остался недовольный. Это и есть неспешный проект.
(33)
Такое с обеих сторон. Что у такого руководителя в отделе на фикси, что у такого франча ничего не сделаешь, не сдашь и не заработаешь. Хоть и говорят о полезности компромиссов, но работать бесплатно не допустимо.
(35)
Деньги идут от живущего проекта, а не коробки. Втюхивать надо лабутены дамам. Это продуктивнее.
(41)
а если это производство, то ВНЕЗАПНО придется составить представление о технологии и предметной области.
(38) требовала, обвинили в бюрократии 🙂
Требовала и когда работала со стороны ИТ заказчика и много позже, когда стала работать на стороне исполнителя. Помогает конечно, но не панацея.
По моему опыту залог успешного внедрения это вовлеченный ответственный пользователь и вовлеченный же представитель заказчика (руководитель) с административным ресурсом. С этой парой можно горы перевернуть. Даже преодолеть молчаливое сопротивление ИТ службы заказчика. Отсутствие заинтересованности одного из них сильно усложняет процесс внедрения, а обоих делает его заведомо неудачным. Для меня самый провальный был проект в котором внедрили, работало, приняли, но продолжили работать в ексель… «потому что привыкли и так проще». Внедряли Документооборот Корп.
(47)»потому что так привычнее» — и не говорите, часто бывает. Внедрили на предприятии автоматизированную систему, но сотрудники «старой закалки» продолжают писать проводки вручную на бумаге карандашиком.
Просто РП должен изначально указать, что подписывать ТЗ должны его потребители. А потребителем выступает будущий пользователь, а не руководитель Заказчика. Руководителю абсолютно неважно какие кнопочки будут на формочках и документах.
(42) из статьи следует, что недовольство было из-за увеличения сроков и бюджета, а также из-за обманутых ожиданий от внедрения. Т.е. не внедренец пострадал, получив первоначально оговоренные деньги и потратив больше часов, а заказчик, оплатив изначально оговоренное и дополнительные работы.
У меня было несколько опытов перерасхода, но пострадал исполнитель (я), не получив прибыль с проекта. А вот заказчик был доволен, хоть и были сорваны все сроки, он получил систему удовлетворяющую ожидания.
Тут, как и почти всегда, проблема в продажниках, продавших не то не туда. А дальше у каждого своя дорожка:
1. отменить проект и разбежаться с минимальными потерями, сразу как только пришло понимание, что мы занимаемся чем-то не тем. (все расстроились)
2. внедрять до победного, за оговоренные ранее деньги (заказчик рад, исполнитель расстроился)
3. внедрять ровно то, что оговорили согласно ТЗ и трясти деньги на допы (заказчик расстроился, мы рады, но делаем вид, что расстроились)
(44) стоимость УПП не маленькая, а маржа франча примерно половина. в зависимости от статуса. Плюс есть такая штука как показатели работы, которые надо выполнять, чтобы быть центром компетенции по производству надо было вывешивать на сайте как много УПП мы внедрили, причем в терминах 1С продажа + бумажка с отзывом = внедрение.
Т.е. стоит у Вас задача стать ЦКП и Вы ориентируете своих продажников на втюхивание УПП, а не УТ, которое как писала девушка было бы логичнее.
(22) Знаю, сам боролся. Но полляма обещали. Правда, заплатили все же 0.4
(54)
Т.е. стоит у Вас задача стать ЦКП и Вы ориентируете своих продажников на втюхивание УПП, а не УТ, которое как писала девушка было бы логичнее.
Вы приписали свои мысли мне и с ними спорите. Все правильно, так сейчас и принято.
Я не продаю, партнер продает. Я — только разработка и внедрение.
А «втюхать», еще раз, не получиться у вас ничего. ЦКП или не ЦКП, без разницы. Что УТ, что УПП потом надо внедрять. Иногда это сложно. Вот про это этот тред.
И да, я часто, бывает слышу критиков вроде вас, которые комментируют посторонние им проекты в определениях «они втюхать хотят». Это как минимум безответственно, потому что заочно. Как минимум..
После рекомендаций иксперта вроде вас, иногда остаются конторы, например, с УТ и десятком баз БП. Попытка потом собрать общую упраленческуюнеуправленческую отчетность сколько будет стоить? Объединение справочников? Не 150 тысяч, примерно на круг? И без разницы есть или нет производство.
А сколько стоит УПП в случае УТ + 10 х БП уже без разницы. Здравый смысл проехали на прошлой станции. «Маржа франча» — не то же что и бонус с продаж менеджера.
И да, 1С собирает «бумажки» о продажах, которые внедрения. И о внедрениях, которые продажа. А что их не надо собирать? И за всей информацией покупателя адресовать в трэды на мисте?
Правильно, нет?
(55)
Я все время пытаюсь это предлагать заказчику. Когда получается, все идет очень энергично.
У вас получилось с внедрением?
(38)
Сценарий — они отказались, директор не настаивает и сам все подписал. Предложил не приставать к его людям и начинать уже работать. Людей указал, доп. оплату им зарубил, от основных обязанностей не освободил даже частично.
И как? Отказаться от проекта, если он сложный?
(47)
С любым документоводом так, не только с 1с. Лечится только принудительно — административной загрузкой всех файлов в инф.базу и почтовыми учетками. Потом бакап и закрытие шары «Общая папка».
Причем грузить надо все, включая mp3 и джипеги с корпоративов. Только сами владельцы файлов могут что-то там рассортировать.
(59)
Неправильный директор. Дело не в отказе от проекта. Просто это один из самых больших «рисков», который потом обязательно вылезет боком.
(48)
Важно ему это. Ему нужно, чтобы те что с карандашиком и проводками сообщили ему, что они теперь пишут проводки в программе.
(62)
Все директора так или иначе «неправильные». У «правильных», как правило, все и так работает.
Тут даже не риск. Нельзя работать без принятых результатов, будет платежный дефолт. А работать надо, вот и пишем ноу-хавы.
(53) возможно, не могу сказать за автора. Но я увидела немного другое. В такой ситуации страдают все и внедренец и заказчик. Не все же меряется полученной прибылью и произведенными расходами. Я вижу недовольство собой, признание того, что неправильно оценила ситуацию. Да. согласна, очень часто продажники продают не то и не тем, но ведь когда я прихожу на проект, я должна его оценить на жизнеспособность. Увидеть и предотвратить какие-то проблемы. Естественно не все, но уж точно больше, чем может увидеть продажник. И вот тогда, на начальном этапе, проговорить эти проблемы и может даже прервать проект. Мне кажется это немного об этом.
Очень уважаю автора за мужество признаться в своих ошибках, в первую очередь себе. На мой взгляд, это очень ценно. И уж в вдвойне — признаться публично.
Спасибо автору, что поделились таким опытом.
(60)у меня было острое желание снести эксель 🙂
(25) Технологических преимуществ от перехода нет.
На 77 используя 1С++ и прямой доступ к данным можно перемалывать огромные объемы, да и просто вынести расчет за пределы транзакции — и вуаля, получите вертолет.
(61)нет, нет. Не путайте, руководителю важен результат — отчет по закупкам/ продажам, бюджеты, проводки и прочее. Всякие «создать на основании», «заполнить по данным», галочки руководителю глубоко безразличны. Ему эти удобства ни к чему.
(63)именно. пишем, а потом оттачиваем, хотя можно было написать с первого раза.
(66) а вот это, самое страшное бомба замедленного действия. .
в курсе, что на десятке 7.7 даже не запускается.?
там получится жуткая смесь бульдога с носорогом, продет еще 3-4 года обновится SQL и перестанет работать 1с++. ну или еще стонить.
там кстати ограничение на 32 а 64 уже во всю.
костыли страшные, сталкивался с таким.
эра 7,7 прошла она была прекрасна, но она прошла. увы.
Есть в сети статья человека который переводил с статического HTML на динамические рельсы.
чем больше тянешь, тем сложнее можно вообще бизнес потерять.
(74)
Не-а! У меня на 64-битной запускается. ЧЯДНТ?
(75) я имел ввиду установщик.
ну да с бубном и еще чем-то можно пустить но это уже изврат.
(67)
Где я путаю? Написал — директор проверит информацию у своих.
Они скажут ему буквально — «стало невозможно работать, это какой-то кошмар..» и вы тоже начнете думать «про галочки».
(66)
На 77 используя 1С++ и прямой доступ к данным можно перемалывать огромные объемы
Просто интересно, вы их наверно и в самом деле перемалываете. Если да, то сколько уже лет точите эту связку 7.7+1С++?
10 лет есть уже? Все туже самую инфобазу или разные?
(75)
Не-а! У меня на 64-битной запускается. ЧЯДНТ?
И на 10-ке запускается и работает под 64-битной ос, но не перестает быть 32-х битной
(80)
На самом деле Вы недооцениваете ценность баз на 7.7 для бизнеса. Дело тут не в технологиях. Бух и ЗиК давно переехали на 8 из-за регламентированной отчетности. В основном живы Торговли и Склад и Комплексные сильно перепаханные. Они настолько заточены под процессы контор, в них столько вложено труда программиста и руководителей. В них идеальная автоматизация всех внутренних процессов. С ними жалко расставаться, получить современный аналог, столь же вылизанный и допиленный стоит очень больших денег.
База на 7.7 скорее всего живет более 15 лет, это значит, что как минимум бизнес успешно пережил все эти 15 лет. Все 15 лет в эту базу вкладывались денежки. даже если бюджеты были маленькие, за 15 лет это уже огого. И руководство и персонал уже привыкли к определенному уровню автоматизации и сделать шаг назад к типовой 8 они не готовы, это потребует увеличения штата сотрудников, а вложиться разово в допиливание 8 до такого же уровня автоматизации и интеграции — дорого, возможно, бизнесу это критичная сумма.
Тут палка о двух концах, нельзя однозначно всех называть динозаврами, диплодоками и мамонтами, которые скоро вымрут. Мы-то (франчи) понятное дело заинтересованы в новых внедрениях и склоняем их к новым проектам и кричим, что 7.7 не поддерживается и спецов по ней уже на рынке труда почти не осталось, но бизнес существующий давно, где директору не 2 года, особенно малый бизнес, он осторожный. Это Вам не заводы, где управленческий состав может меняться раз в 5 лет и новый директор не ценит и не знает сколько труда было вложено в «старушку» и как она хороша.
Не подумайте, что я защитник 7.7, я люблю новые технологии и мне приятнее ковыряться в «Такси», чем в «старушке», но старость надо уважать
(87) но старость надо уважать
безусловно уважать и на пенсию провожать.
мне тур рассказали что была на одном предприятии 7,7, всем нравилась, но пришло время обмениваться инфой (или интегрироваться куда-то), а все 7.7 не поддерживает и все.. потеряли контракт.
(90) у подруги сестры ее мужа друга….. можно больше конкретики?
(90) если речь о готовой интеграции с чем-то, то да функционал УТ шире. А по технологиям в 7.7 все есть, вопрос только найти разработчика «старичка» с руками — это сложнее год от года
(94) если это ларек с шавермой или цветочный да без проблем можно 6.0 вкорячить.
(91) вкраце столовка была на заводе, кормила работяг , руководство завода решило компенсировать работягам еду.
надо было ПО столовки съинтергрировать с Заводским ЗУП (причем стандатно по КД 3,0 так как модуль уже есть.).
и все столовку(подрядчика с 7.7) выгнали наняли другого подрядчика.
вот так вот древние технологии мешают бизнесу.
(95) типовой общепит 7.7 заменили на типовой общепит 8, удивили, делов на 5 минут 🙂
(96)
кто сказал что он типовой, так было вырисовано на 7,7 себестоимость блюд итд.
Вообщем все здорово сделано всех устраивало, 1с ++ там и куча всего.
внедрить общепит за 5 минут?? обучить всех официантов, поваров-сметчиков ??? да вы Чак Норрис от 1с.
(95) так а что мешало интегрировать не по КД 3?
ИМХО: Это не древние технологии, а формальный повод слезть с 7.7 и отказаться от подрядчика, мне думается все же написать обмен было дешевле чем внедрять «работающую» систему ))))
(98) так а что мешало интегрировать не по КД 3
мешало то что остальные столовки холдинга уже интегрированы.
и ради одной столовки, нанимать подрядчика и проводить какие-то костыли в систему, совсем не хотелось им проще сменить столовку.
это смотря с кокой колокольни смотреть.
(87) Вы сейчас как будто историю из начала 90-х про замену счетов (которые абак) на калькуляторы рассказали. «Мы вложили столько средств в покупку счетов, что покупать калькуляторы мы не будем!»
Это первое, а второе — как показывает практика, развивать — а проще говоря постоянно допиливать — систему на 77 выгодно только придворному программисту, самому предприятию нафик не надо вкладывать постоянно бабло в «уникальную» систему, которую на рынке современного ПО можно купить за три рубля.
Про моральное устаревание объяснять, наверное, не надо?
.
(47)
Заинтересованный ответственный пользователь, это залог успеха, правда.
(60) 1с документооборот это рак, все разговоры внедренцев о том, как мы настраивали права в документообороте.
(87)
База на 7.7 скорее всего живет более 15 лет, это значит, что как минимум бизнес успешно пережил все эти 15 лет. Все 15 лет в эту базу вкладывались денежки. даже если бюджеты были маленькие, за 15 лет это уже огого. И руководство и персонал уже привыкли к определенному уровню автоматизации и сде
Просто я давно придерживался правила, если управленческая система работает хорошо, её не надо трогать и переписывать. нужно адаптировать. ну речь не только о 7.7 скорее об ут 10.3. но в целом подход правильный, если что-то работает хорошо, не суй эту МЕГАУНИВЕРСАЛЬНУЮТИПОВУЮДЛЯВСЕХСТОРМОЗАМИОТ1с. У фирмы 1с свои цели, у бизнеса в конкретной ситуации — свои. Так что все относительно, в одной ситуации нужен новый продукт, в другой — старый друг лучше новых 2х.
(100)
«придворному» программисту это 5!
(100)
Очень у вас странные подход…
Звучит как менять программу ради смены программы.
Если старая система не нуждается в доработках и сравнима с новой, то зачем менять?
про ситуацию с КД 3.0 — что мешало сделать интеграцию на КД 2.1 или файликами? Или это было дороже, чем внедрение новой программы и последующие её допилы?
Очень хорошее правило озвучивал в интервью главный архитектор одноклассников Андрей Анастасьев — правило большого З. При любой доработке задавай вопрос Зачем? (какие проблемы это решает).
Куча проблем снимается…в том числе и переход на новые версии чего бы то ни было.
(105)
Меня чесслово поражает способность людей читать то, что не написано. Где я говорил менять программу ради программы? Я же по моему достаточно четко объяснил конкретно для случаев доработок: а) достаточно часто выгодно дорабатывать программу на предприятии только конкретному программисту, а не предприятию как таковому (хотя Кобол в банках еще живет, да) б) на рынке есть программы, где то, что будет дорабатывать программист дешевле купить (только не надо про дорогой перенос и прочее — эксплуатация старой машины зачастую на долгосрочной дистанции дороже, чем покупка новой) в) есть моральное устаревание — как один из примеров: когда вокруг уже вовсю пользуются плюшками веб-серверов и облаков, предприятие до сих пор делает обмен почтовыми программами.
Если Вы пользуетесь нокией 3310 — это же прекрасно! И зачем смартфон покупать, функциональность то сравнима! Ключевые задачи — связь и выход в интернет — ведь выполняет! Легко так заходишь в интернет — и вуаля, работаешь!!! У Вас, кстати, какой телефон?))
PS Про КД2.1 и 3 — Вы принципиально не понимаете, что многим клиентам технические детали НЕ ВАЖНЫ. Клиенту важны отработанные бизнес-процессы (извините за пафос). У него стоит вот такая система работы на скольки-то точках — на остальных будет также. Внутренний стандарт, понимаете? Это как принтер — если покупаешь на торговые точки, желательно чтобы был принтер под один картридж и было легко все поменять и настроить. Инструмент покупается-подстраивается под работу — а не наоборот.
(99)
Причем тогда здесь 7.7 не позволяет провести интеграцию… )))))), ситуация кардинально другая и переход более чем оправдан.
про ситуацию с КД 3.0 — что мешало сделать интеграцию на КД 2.1 или файликами? Или это было дороже, чем внедрение новой программы и последующие её допилы? (105)
Причем тогда здесь 7.7 не позволяет провести интеграцию… )))))),
лио я не так объясняю либо вы чего о не понимате.
Есть большой завод АО . у них кд 3.0 все.
они нанимают мелкие ООО ИП в качестве столовок, так как большому заводу, получать все разрешения итд… это год займет.
у них есть ERP обмен 3,0 .
они выставляют конкурс, важные детали интеграция с нашим КИС , интеграция должна быть по 3,0 все..
не можешь проходи мимо.
так люди теряют деньги оставаясь на 7,7 итд …
(108)
Ну, видимо выгоды особой не было от внедрения обмена через Enterprise Data в 7.7, хотя такие решения существуют, неужели никто не взялся?
(109) представляю, что это за изврат.
да вообще там разговор короткий был, типа у вас КД3 нет, тогда до свидания.
прошли те времена когда можно было нанять девочку, чтоб вбивала данные с листа.
(97)
не буду спорить, я хороший 1С`ик 🙂
(110) да почему изврат? 🙂
в 7.7 есть поддержка XML, а КД 3.0 это не что иное как обычный обмен через XML с условием, что все имена тегов и атрибутов заранее определены. В теории можно на КД 2 написать обмен с некой конфигурацией по структуре равной формату Enterprise Data. Уверен, что это уже делали.
(87) Добавлю, что и подход совершенно разный — у 7.7 и 8.х.
Свобода и почти нативное программирование в 7.7 (т.е. если сравнивать именно сегмент 1С-продуктов), и рельсы, зажатость, и программирование через не то место в 8-ках.
Поэтому и живут 7.7-базы 15 и более лет, поэтому же и не хотят с ними расставаться. Минимум — ставят задачу получить такой же функционал.
А в рамках перехода с 7.7 на 8.х (и вообще у 1С) это невозможно.
(113) это невозможно хотя бы потому, что не все типы данных 7.7 конвертируются в текст, т.е. в пресловутый (и всеми, почему-то, любимый) XML.
Взять хотя бы периодический реквизит.
Вообще, у 1С изначально, что в 7-ках, что далее, неправильный подход к типам данных: вместо унификации и базировании на примитивных типах — постоянно ваяют новые и новые типы, что периодический реквизит в 7.7, что NULL-НЕОПРЕДЕЛЕНО в 8, не говоря уже про все эти бесконечные «Справочник.», «Документ.», «Регистр.».
у 1С даже типы регистров внутри 8-ок несовместимы между собой. А ведь изначально это — просто реляционные таблицы, только изуродованные до неузнаваемости.
(110) Коллега давайте наверно подведем итог и прекратим флуд не по сабжу, слишком сильно в сторону ушли ))))
ИТОГ: В рамках приведения к однообразию было принято решение перейти на новый продукт, успешно внедренный в других подразделениях холдинга.
Техническая возможность/невозможность решения на 7.7 не причем, от слова совсем ))).
(60)
Причем грузить надо все, включая mp3 и джипеги с корпоративов.
Ну попробуйте загрузить 50-100 Гб подобного «информационного мусора» в 1С — и получите полностью нерабочую по причине тормозов базу.
Только Oracle-SQL, только нормализованные таблицы.
90% всех данных — это архивные данные, становящиеся таковыми либо сразу при создании, либо — спустя какое-то время.
И общую базу всех «шар» делают не для того, чтобы постоянно там чего-то лопатить, а чтобы можно было делать централизованный бекап, т.е чтобы данные не потерялись.
А пользоваться ими могут и раз в сто лет.
(117)
Только Oracle-SQL, только нормализованные таблицы.
90% всех данных — это архивные данные, становящиеся таковыми либо сразу при создании, либо — спустя какое-то время.
И общую базу всех «шар» делают не для того, чтобы постоянно там чего-то лопатить, а чтобы можно было делать централизованный бекап, т.е чтобы данные не потерялись.
А пользоваться ими могут и раз в сто лет.
1. грузил. рабочая. а ты?
2. без разницы. ты недавно прочитал про нормализацию?
3. я знаю что и кому нужно на шарах и сколько там лежит и чего. уже лет 20 как в курсе.
пиши еще
(115)
Понятно с поциентом.
(115)
Если вас окружают бараны, возможно вы — главный. (Не мое)
(2) А еще удобная help — справка к документам, отчетам, справочникам. Что даже 1С-ка не всегда делает 🙂
(45) И вот тут ты становишься тем самым загадочным «Программистом 1С» … 🙂