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

09.06.17

Управление проектом - Кейсы проектов

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

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

С точки зрения традиционных подходов проект успешный, если он закончился в срок и в рамках отведенного бюджета. Но я бы сюда еще добавила удовлетворенность заказчика, потому что в нашем бизнесе просто подписать акты недостаточно. Хотелось бы, чтобы клиенты отзывались о компании положительно, и, в идеале, принимали референсы.

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

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

Основной причиной перехода было постепенное «умирание» базы из-за объема: она занимала под сотню Гб (тут могу ошибаться), и еще имела несколько распределенных узлов: документы еле «ползали», стоимость материалов уже не считалась. А бизнес расширялся, и собственники опасались, что еще одного года база не переживет.

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

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

В то время требование: торговля + себестоимость + бюджетирование - означали УПП. Тем более, что мы в то время специализировались в основном на внедрении данного программного продукта.

Первую фазу внедрения – проработку Функциональной модели - мы начали в мае-июне. Уже сразу стало понятно, что программный продукт в части торгового блока не подходит им на 90%. У них было отдельно ведение клиентов и партнёров, деление номенклатуры на сегменты с разным ценообразованием для разных категорий покупателей. Были справочные адресные склады и подписки клиентов на события. И еще много чего, что в то время уже было частично реализовано в УТ11.

Наверное, сейчас бы я вовремя рассмотрела варианты с другими конфигурациями. Точнее, предоставила бы заказчику всю информацию, в том числе предложила запустить второе параллельное моделирование процессов на УТ 11. Да, это стоило бы им дополнительных денег, но позволило бы принять более осмысленное решение и, возможно, снизило бы риски внедрения. Не знаю, куда бы вывернул проект в таком случае (на нем хватало и других проблем). Но с тех пор я стараюсь, во-первых, во время признавать свои ошибки. А, во-вторых, вовлекать в процесс принятия решений руководство заказчика.

 ФМ на УПП шел очень тяжело. Пользователи не видели нужного им функционала, и буквально все приходилось объяснять друг другу «на пальцах». В итоге концепт мы все-таки защитили, но он предполагал почти 200 доработок объемом под 4 тысячи человеко-часов. Бюджета на такое дело у них не было, так что от половины (!!!) доработок было решено отказаться, а оставшуюся часть поделить пополам с их ИТ-службой.

Даже объем в 1 тысячу часов кодирования мы на тот момент еще ни разу не «поднимали». Это сейчас уже понятно, зачем нужны интеграционные тесты, формализация требований к общим справочникам и так далее. Но в то время я просто решила набрать на проект побольше программистов (некоторые «выжившие» вспоминают то кодирование до сих пор).

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

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

Все это «вылезло» на этапе первого контакта системы с реальными пользователями, и привело к 400м часов запросов на изменение (то есть почти 50% от нашего объема доработок). Примерно столько же «прилетело» и на ИТ-службу, что, конечно же, не улучшило наших отношений.

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

Уже гораздо позже, по результатам полученного (через кровавые слезы) опыта у нас в фирме родился документ «Стандарты кодирования», в котором мы описали (и актуализируем до сих пор) основные принципы разработки.

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

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

Разработку мы должны были закончить в январе, чего, конечно же, сделать не успели. Февраль-март ушли на доведение системы до ума и на интеграцию с доработками, которые сделала к тому времени ИТ-служба заказчика, наступавшая на те же грабли.

А в апреле мы совместно пошли сдавать систему ключевым пользователям, и это было мероприятие в стиле «я кинул атомную бомбу, и она жахнула…». Начались истерики, швыряния документов и бесконечные совещания.

Спасло меня в тот момент только наличие подписанных технических заданий (всегда прикрывай «пятую точку» бумажкой, ибо никто не знает, когда что выстрелит). Заказчик скрипел зубами, но платил за переработку. Правда,  его лояльность быстро упала «ниже плинтуса».

Сейчас мы, конечно, уже так не работаем. За 15 лет работы в этом бизнесе я еще не встретила заказчика, который может на этапе ФМ или даже ТЗ полностью осмыслить будущее поведение системы. Все равно на этапе эксплуатации вылезают вещи, которые надо подправлять. В определенный момент я приняла этот факт как данность, и теперь просто закладываю в стоимость доработок примерно 20% на их «допиливание» на ходу. Клиенту проще один раз пережить большой бюджет, чем каждую неделю бегать к собственнику с допниками.

Также в ОПЭ я закладываю время на работу программиста: просто на отчеты или печатные формы, про которые все забыли на этапе ФМ, и прочие «бантики».

Нужно ли в таких условиях согласовывать ТЗ? Да, нужно, потому что с ним можно в любой момент остановиться, отметая откровенную «ересь».

На проекте с запросами на изменение мы провозились до середины мая. Дальше сдвигаться возможности уже не было, окошко «закрывалось». Приняли решение стартовать 20го мая, не смотря ни на что.

В первый же день прилетела вторая «атомная бомба»: как оказалось, выделенные в апреле ключевые пользователи тоже не владели полной информацией: были люди (а иногда и целые отделы), которые работали «чуть-чуть по-другому». GoLive Tracking рос как снежный ком, и в нем было 2 статуса: «исправить до завтра» и «исправить немедленно». Программисты (и наши, и их) работали по 14 часов в сутки, поедая часы на ОПЭ с экстремальной скоростью. В итоге заказчик «забил» на бюджетирование и «забил» на себестоимость. Весь бюджет был перенаправлен на доведение системы хоть до какого-то приемлемого состояния.

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

Акты нам подписали, но ни о каком положительном отзыве не могло быть и речи. Общий перерасход часов по всем работам составил 30%. Реальный перерасход – больше 50%.

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

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

Здесь надо себя просто переломить: основная функция РП – это двигать проект в нужном направлении и с нужной скоростью. Под «двигать» я имею в виду как своих спецов, так и Заказчика (то, что его сотрудники не горят желанием взваливать на себя доп.работу нормально – им за это редко доплачивают). В некоторых книгах по управлению проектам пишут, что РП на проекте вообще должен управлять только рисками: то есть постоянно прогнозировать (самому и с помощью проектной команды), что именно на проекте может пойти не так. И, самое главное, увидеть, что процесс где-то затормозился, объективно оценить причину и во время среагировать, чтобы не попасть в пресловутую ловушку «98-ми процентов».

В провале проекта почти всегда виноват именно его менеджер – в какой-то момент приходится это принять и начать работать над собой.

Закончить хочу словами Джо Мараско (за точность цитаты не ручаюсь): «проекты похожи на восхождение альпинистов – трудно планировать, важна слаженность команды и природа по определению сильнее тебя. Однако есть альпинисты, которые водят группы успешнее других».

Предыдующие публикации на тему управления проектами:

Управление проектами

См. также

Импортозамещение. Перевод промышленного предприятия с M3 Infor на 1С:ERP за 2 месяца по технологии SCRUM

Кейсы проектов Бесплатно (free)

Когда проект ограничен по времени, и уже через два месяца заказчик физически не сможет работать в старой системе, нет времени обкладываться бумажками – нужно быстро подготовить новую систему к переходу. Расскажем о том, как гибкие технологии SCRUM и ТБР помогли за два месяца адаптировать 1С:ERP под существующие бизнес-процессы компании.

07.02.2024    2534    0    izybaevda    18    

16

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

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2734    0    1СERP    21    

31

Управление проектами при разработке мобильных приложений

Кейсы проектов Бесплатно (free)

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

12.09.2023    988    0    chat007    0    

5

Как мы сделали крупнейший международный проект 1С:ERP

Кейсы автоматизации Кейсы проектов Кейсы продуктов Бесплатно (free)

В управлении проектами нет однозначных рецептов, особенно при взаимодействии с заказчиком из другой страны и другой культуры в проектах перехода из принципиально другой исторической системы. Расскажем об истории крупнейшего международного проекта перехода с SAP на 1С:ERP.

01.09.2023    1635    0    olegminkov    2    

8

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14232    0    ASchekachev    37    

55

Радио "Аналитик", выпуск 18. О мифах, которые рождаются вокруг продуктов с Алексеем Чернышовым

Кейсы проектов Бесплатно (free)

В восемнадцатом выпуске подкаста Радио “Аналитик“ обсудили, что делать, если ценность продукта не очевидна для пользователя, какие трудности могут возникнуть при изменении позиционирования продукта и как с ними справиться.

15.05.2023    530    0    Radio_Analyst    0    

1

Переход с УПП на ERP. Сложности выверки регламентированного учета при «плавном переходе»

Кейсы проектов Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 Бухгалтерский учет Бесплатно (free)

На конференции Infostart Event 2022 Saint Petersburg выступил генеральный директор компании MoscowSoft Сергей Сорокин. Он рассказал про актуальность проектов перехода с УПП на ERP, рассмотрел риски при переходе и типовые сложности, которые возникают при сопоставлении документов и других объектов конфигураций.

05.05.2023    2576    48    primat    0    

9

Как мы «завалили» проект SaaS ERP-системы за 0,5 млн евро

Кейсы проектов Бесплатно (free)

Не стыдно иметь опыт провальных проектов. Стыдно не делать выводов из провалов и не улучшать свои подходы к работе. На конференции Infostart Event 2021 Moscow Premiere Илья Отькало рассказал об уникальном проекте создания SaaS ERP-системы для туроператоров с многоканальной схемой дистрибуции, который, несмотря на вложение полмиллиона евро, все-таки пришлось закрыть.

30.03.2023    4827    0    otkalo    4    

13
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. igormiro 714 09.06.17 17:11 Сейчас в теме
Интересная статья. "Также в ОПЭ я закладываю время на работу программиста: просто на отчеты или печатные формы, про которые все забыли на этапе ФМ, и прочие «бантики»." - какие бантики?
2. корум 287 09.06.17 17:55 Сейчас в теме
(1)
какие бантики?

удобная справка по состоянию заказов, печать счета из заказа, загрузка прямо в документ из ёкселя и туча других плюшек, что щедро раскиданы по старой системе, о которых никто не вспоминает до момента ввода новой системы в эксплуатацию...
Lacrimosa0000; hilton008; +2 Ответить
161. protexprotex 126 29.09.17 20:14 Сейчас в теме
(2) А еще удобная help - справка к документам, отчетам, справочникам. Что даже 1С-ка не всегда делает :-)
15. timeforlive 15 10.06.17 18:52 Сейчас в теме
(1) справочная информация и вовсе забывается (в т.ч. инструкции для конечных пользователей).
Сотрудники меняются и начинается бегство к программерам с вопросами "а куда дальше нажимать" или "ЧЯСНТ" (что я сделал не так).
У нас в фирме было так (у многих так).
23. 1СERP 3045 13.06.17 12:11 Сейчас в теме
(1)
Спасибо. В дискуссиях в предыдущих статья коллеги просили поделиться опытом реальных не особо успешных проектов. Эта статья - первый такой опыт
3. rpgshnik 3623 09.06.17 18:08 Сейчас в теме
Такие статьи на порядок полезнее успешных внедрений.
sergeyap; maksa2005; iulyus; Kinestetik; ShestakovVitaly; DimaP; Saint13; vovan_victory; Dragonim; swimdog; andron77777; demkonst; Artem-B; o.nikolaev; корум; i1381215@trbvm.com; orfos; Leja; Kotta; Wrols; Maxis; Stim213; hilton008; Serega-artem; Бывалый77; АльфаАвтоПрограммист; FilatovRA; Obertone; DeD MustDie; Светлый ум; brr; AlexK_2012; FreeArcher; Samarin; serg_gres; smirnov.es; baracuda; pallid; Сурикат; davdykin; +40 1 Ответить
24. 1СERP 3045 13.06.17 12:11 Сейчас в теме
(3)
Спасибо. Передам автору.
4. RAV38574 119 09.06.17 23:49 Сейчас в теме
Беда в том, что пытаетесь воспроизвести то что было - зачем?
Используя типовой механизм, надо оптимизировать бизнес процессы клиента под них, а уж потом кодировка. Или смена типовой.
Начинать надо с бизнес процесса компании, а не то что было. В результате хотелок менеджеров приводится конфигурация к дому без фундамента. Просто не представляю зачем переписывать на 90%. Тогда уж ТЗ подробное и с 0 строго по ТЗ, а хотелки неучтенные, после сдачи проекта хоть годами дорабатывать. Чума а не внедрение у Вас было.
dk77; ShestakovVitaly; eugenty; manlak; Spacer; wazup666; Vladimir Litvinenko; dimpson; Aleskey_K; Serega-artem; АльфаАвтоПрограммист; KazanKokos; baracuda; +13 Ответить
8. d4rkmesa 10.06.17 11:23 Сейчас в теме
(4)
Может, потому что речь об УПП? Мне очень знакомо подобное внедрение, успешное правда, с самописки на базе 7.7 на УПП с доработками, правда, в другой отрасли(пищепром - производство + оптовая торговля + логистика, полный цикл). На типовой УПП уже бы на 2-й день все либо встало, либо как то работало с неимоверными усилиями сотрудников, которые уже на 2-й день устроили бы бунт, т.к. работать круглосуточно не может никто. Элементарный цикл: прием заказов - резервирование и оформление - планирование логистики - отбор и доставка по клиентам, уже на этапе логистики бы столкнулся с трудностями, т.к. фактически этого функционала в УПП нет. Ну допустим в Excel-е логисты все сделали, дальше у склада увлекательная задача - разложить все по машинам "по бумажкам" (распечатанным Торг-12). Плюсуем человеческий фактор - и доставка фактически либо сорвана, либо осуществляется с существенным опозданием. На след. день руководство дает всем по шапке и внедрение откатывается.
IvanovAV; Dementor; +2 Ответить
9. nickperel 5 10.06.17 13:20 Сейчас в теме
Спасибо, что вы продолжаете цикл.
Если захотите продолжить, раскройте подробнее практику работы с локальной ИТ - службой (управлением, отделом, просто отдельным программистом) или ответственным лицом.

Частая ситуация - после контакта с ключевым лицом заказчика (директором), приходишь к соглашению внедрять типовую и "оптимизировать процессы".

Получаешь адаптированную и работающую инфобазу (например, УПП).
Смотришь в код - там справочники "Материалы" и "Себестоимость" каких-то наборов, функции, которые выдают цену, через установленные внутри переменные метров и времени суток.
Все это работает, но им кое-что хочется доделать. Кроме того, хотят получить функциональность новой ERP. Все одновременно.

Если ультимативное требование - два месяца, то предлагаешь к этому строку начать работать на 50%, если все это время клиент будет учиться пользованию ERP.
С большими цифрам покрытия бизнес процессов никогда никто почему то не согласен.
Доработанное УПП портировать по функциональности, а не коду. Это не два месяца и сотни часов.
А то и год, как пойдет..
Тут могут сразу сказать, что хотели решение "с полки", никаких "с год.." и отвалиться. Это ладно..

Потом требуешь человека, который будет все это время ответственно принимать решения по пригодности модели к переносу и потом разрешать оплаты\предоплаты, принимать работу.
Нельзя говорить, что это не сложно и мы вместе можем придти к тому, что портировать придется 10% прежнего. Люди не любят быть типовыми.

Клиент может отвалится сразу, поняв что он сам - обязательная часть хода проекта. Это ладно..
Часто стрелка указывает на специалиста в штате - т. н. "программиста 1С". Что вообще означает это название в стране никто не знает.
И иногда это, внезапно, и есть программер старой системы , но он объективно не заинтересован. Он как бы все и так уже сделал и хотел бы работать над недостатками старой системы.

Если на месте "программиста 1С" сидит сисадмин, то может начаться разговор "...почему не SAP, это несерьезно..".
Но работу принимать он будет, участвовать - нет. Все попытки подходить с проблемами будет адресовать выше себя или в сторону. То есть в никуда.

Если это управление ИТ или отдел, все тоже самое, только роль "программист 1С" назначена группе людей. От этого дело бодрее не идет. Они даже саботируют с черепашьей скоростью :-)

И потом, во всех объявлениях о найме "программиста 1С" указано "не конфликтность". То есть наверно надо "не склочность", но человек из ИТ всегда опасается, что его участие могут интерпретировать как нелояльное конторе.

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

Короче, интересно было бы почитать про приемы и практику решения проблем взаимодействия.
Жать на пролетарскую сознательность и убеждать, апеллируя к корпоративности всея программеров планеты Земля, можно, но очень надоело и крайне медленно.

Сложился ли какой-то формат работы в проекте для локального ИТ, кроме того что они просто фактически переподчиняются подрядчику и исполняют все безусловно?
Простая механика отката сразу переводит отношения в подземный уровень и тоже ничего не решает и сильно может навредить.
DimaP; Winstoncuk; ZUL_MTFKA; DeD MustDie; +4 Ответить
25. 1СERP 3045 13.06.17 12:15 Сейчас в теме
(4)
Вы, конечно, правы.
Только "на берегу" было ограничение:
Предыдущая система, вцелом, устраивала Заказчика. Причина перехода - преимущественно, технологическая. Поэтому клиент не особо был настроен на "оптимизацию бизнеспроцессов". Поэтому и основными заказчиками оказалась ИТ-служба, а не бизнес.
Больше мы на такое "не ведемся".
rovenko.n; +1 Ответить
66. zarucheisky 19.06.17 11:11 Сейчас в теме
(25) Технологических преимуществ от перехода нет.
На 77 используя 1С++ и прямой доступ к данным можно перемалывать огромные объемы, да и просто вынести расчет за пределы транзакции - и вуаля, получите вертолет.
IvanovAV; +1 Ответить
74. hillsnake 35 20.06.17 16:33 Сейчас в теме
(66) а вот это, самое страшное бомба замедленного действия. .
в курсе, что на десятке 7.7 даже не запускается.?

там получится жуткая смесь бульдога с носорогом, продет еще 3-4 года обновится SQL и перестанет работать 1с++. ну или еще стонить.
там кстати ограничение на 32 а 64 уже во всю.
костыли страшные, сталкивался с таким.
эра 7,7 прошла она была прекрасна, но она прошла. увы.

Есть в сети статья человека который переводил с статического HTML на динамические рельсы.
чем больше тянешь, тем сложнее можно вообще бизнес потерять.
eeeio; Maxx2008; DimaP; Winstoncuk; +4 Ответить
80. nickperel 5 21.06.17 18:06 Сейчас в теме
(66)
Технологических преимуществ от перехода нет.
На 77 используя 1С++ и прямой доступ к данным можно перемалывать огромные объемы

Просто интересно, вы их наверно и в самом деле перемалываете. Если да, то сколько уже лет точите эту связку 7.7+1С++?
10 лет есть уже? Все туже самую инфобазу или разные?
75. sssss_aaaaa_2011 20.06.17 17:03 Сейчас в теме
(74)
в курсе, что на десятке 7.7 даже не запускается.?
Не-а! У меня на 64-битной запускается. ЧЯДНТ?
IvanovAV; EliasShy; Gluk_1C; monkbest; +4 Ответить
87. monkbest 115 22.06.17 07:31 Сейчас в теме
(80)

На самом деле Вы недооцениваете ценность баз на 7.7 для бизнеса. Дело тут не в технологиях. Бух и ЗиК давно переехали на 8 из-за регламентированной отчетности. В основном живы Торговли и Склад и Комплексные сильно перепаханные. Они настолько заточены под процессы контор, в них столько вложено труда программиста и руководителей. В них идеальная автоматизация всех внутренних процессов. С ними жалко расставаться, получить современный аналог, столь же вылизанный и допиленный стоит очень больших денег.
База на 7.7 скорее всего живет более 15 лет, это значит, что как минимум бизнес успешно пережил все эти 15 лет. Все 15 лет в эту базу вкладывались денежки. даже если бюджеты были маленькие, за 15 лет это уже огого. И руководство и персонал уже привыкли к определенному уровню автоматизации и сделать шаг назад к типовой 8 они не готовы, это потребует увеличения штата сотрудников, а вложиться разово в допиливание 8 до такого же уровня автоматизации и интеграции - дорого, возможно, бизнесу это критичная сумма.

Тут палка о двух концах, нельзя однозначно всех называть динозаврами, диплодоками и мамонтами, которые скоро вымрут. Мы-то (франчи) понятное дело заинтересованы в новых внедрениях и склоняем их к новым проектам и кричим, что 7.7 не поддерживается и спецов по ней уже на рынке труда почти не осталось, но бизнес существующий давно, где директору не 2 года, особенно малый бизнес, он осторожный. Это Вам не заводы, где управленческий состав может меняться раз в 5 лет и новый директор не ценит и не знает сколько труда было вложено в "старушку" и как она хороша.

Не подумайте, что я защитник 7.7, я люблю новые технологии и мне приятнее ковыряться в "Такси", чем в "старушке", но старость надо уважать
itline67; user1831457; sasha12369; Kinestetik; practik1c; kontragent; IvanovAV; DimaP; DarkUser; EliasShy; maxopik2; Adilgeriy; Winstoncuk; fd13; AlexO; Gluk_1C; 1cmax; +17 Ответить
76. hillsnake 35 20.06.17 17:38 Сейчас в теме
(75) я имел ввиду установщик.
ну да с бубном и еще чем-то можно пустить но это уже изврат.
83. nickperel 5 21.06.17 18:13 Сейчас в теме
(75)
в курсе, что на десятке 7.7 даже не запускается.?
Не-а! У меня на 64-битной запускается. ЧЯДНТ?


И на 10-ке запускается и работает под 64-битной ос, но не перестает быть 32-х битной
Kinestetik; IvanovAV; Winstoncuk; Gluk_1C; hillsnake; +5 Ответить
90. hillsnake 35 22.06.17 10:05 Сейчас в теме
(87) но старость надо уважать
безусловно уважать и на пенсию провожать.

мне тур рассказали что была на одном предприятии 7,7, всем нравилась, но пришло время обмениваться инфой (или интегрироваться куда-то), а все 7.7 не поддерживает и все.. потеряли контракт.
100. АльфаАвтоПрограммист 23.06.17 14:44 Сейчас в теме
(87) Вы сейчас как будто историю из начала 90-х про замену счетов (которые абак) на калькуляторы рассказали. "Мы вложили столько средств в покупку счетов, что покупать калькуляторы мы не будем!"
Это первое, а второе - как показывает практика, развивать - а проще говоря постоянно допиливать - систему на 77 выгодно только придворному программисту, самому предприятию нафик не надо вкладывать постоянно бабло в "уникальную" систему, которую на рынке современного ПО можно купить за три рубля.
Про моральное устаревание объяснять, наверное, не надо?
.
AliceLight; vovan_victory; rovenko.n; +3 Ответить
91. Gluk_1C 22.06.17 10:30 Сейчас в теме
(90) у подруги сестры ее мужа друга..... можно больше конкретики?
94. monkbest 115 22.06.17 14:20 Сейчас в теме
(90) если речь о готовой интеграции с чем-то, то да функционал УТ шире. А по технологиям в 7.7 все есть, вопрос только найти разработчика "старичка" с руками - это сложнее год от года
95. hillsnake 35 22.06.17 14:54 Сейчас в теме
(94) если это ларек с шавермой или цветочный да без проблем можно 6.0 вкорячить.

(91) вкраце столовка была на заводе, кормила работяг , руководство завода решило компенсировать работягам еду.
надо было ПО столовки съинтергрировать с Заводским ЗУП (причем стандатно по КД 3,0 так как модуль уже есть.).
и все столовку(подрядчика с 7.7) выгнали наняли другого подрядчика.
вот так вот древние технологии мешают бизнесу.
96. monkbest 115 22.06.17 15:03 Сейчас в теме
(95) типовой общепит 7.7 заменили на типовой общепит 8, удивили, делов на 5 минут :)
98. Gluk_1C 23.06.17 12:02 Сейчас в теме
(95) так а что мешало интегрировать не по КД 3?
ИМХО: Это не древние технологии, а формальный повод слезть с 7.7 и отказаться от подрядчика, мне думается все же написать обмен было дешевле чем внедрять "работающую" систему ))))
IvanovAV; корум; 1cmax; +3 Ответить
97. hillsnake 35 22.06.17 15:22 Сейчас в теме
(96)


кто сказал что он типовой, так было вырисовано на 7,7 себестоимость блюд итд.
Вообщем все здорово сделано всех устраивало, 1с ++ там и куча всего.

внедрить общепит за 5 минут?? обучить всех официантов, поваров-сметчиков ??? да вы Чак Норрис от 1с.
maxopik2; Winstoncuk; rovenko.n; +3 Ответить
99. hillsnake 35 23.06.17 13:00 Сейчас в теме
(98) так а что мешало интегрировать не по КД 3

мешало то что остальные столовки холдинга уже интегрированы.

и ради одной столовки, нанимать подрядчика и проводить какие-то костыли в систему, совсем не хотелось им проще сменить столовку.
это смотря с кокой колокольни смотреть.
107. Gluk_1C 26.06.17 15:57 Сейчас в теме
(99)
мешало то что остальные столовки холдинга уже интегрированы

Причем тогда здесь 7.7 не позволяет провести интеграцию... )))))), ситуация кардинально другая и переход более чем оправдан.
112. monkbest 115 28.06.17 13:28 Сейчас в теме
(97)
да вы Чак Норрис от 1с

не буду спорить, я хороший 1С`ик :)
IvanovAV; tailer2; +2 Ответить
104. 1cmax 152 25.06.17 01:19 Сейчас в теме
(100)
придворному
"придворному" программисту это 5!
murzilka88; AliceLight; +2 Ответить
105. Сурикат 392 25.06.17 21:21 Сейчас в теме
(100)
Очень у вас странные подход...
Звучит как менять программу ради смены программы.
Если старая система не нуждается в доработках и сравнима с новой, то зачем менять?

про ситуацию с КД 3.0 - что мешало сделать интеграцию на КД 2.1 или файликами? Или это было дороже, чем внедрение новой программы и последующие её допилы?

Очень хорошее правило озвучивал в интервью главный архитектор одноклассников Андрей Анастасьев - правило большого З. При любой доработке задавай вопрос Зачем? (какие проблемы это решает).

Куча проблем снимается...в том числе и переход на новые версии чего бы то ни было.
106. АльфаАвтоПрограммист 26.06.17 11:35 Сейчас в теме
(105)
Меня чесслово поражает способность людей читать то, что не написано. Где я говорил менять программу ради программы? Я же по моему достаточно четко объяснил конкретно для случаев доработок: а) достаточно часто выгодно дорабатывать программу на предприятии только конкретному программисту, а не предприятию как таковому (хотя Кобол в банках еще живет, да) б) на рынке есть программы, где то, что будет дорабатывать программист дешевле купить (только не надо про дорогой перенос и прочее - эксплуатация старой машины зачастую на долгосрочной дистанции дороже, чем покупка новой) в) есть моральное устаревание - как один из примеров: когда вокруг уже вовсю пользуются плюшками веб-серверов и облаков, предприятие до сих пор делает обмен почтовыми программами.
Если Вы пользуетесь нокией 3310 - это же прекрасно! И зачем смартфон покупать, функциональность то сравнима! Ключевые задачи - связь и выход в интернет - ведь выполняет! Легко так заходишь в интернет - и вуаля, работаешь!!! У Вас, кстати, какой телефон?))

PS Про КД2.1 и 3 - Вы принципиально не понимаете, что многим клиентам технические детали НЕ ВАЖНЫ. Клиенту важны отработанные бизнес-процессы (извините за пафос). У него стоит вот такая система работы на скольки-то точках - на остальных будет также. Внутренний стандарт, понимаете? Это как принтер - если покупаешь на торговые точки, желательно чтобы был принтер под один картридж и было легко все поменять и настроить. Инструмент покупается-подстраивается под работу - а не наоборот.
rovenko.n; Dementor; +2 Ответить
108. hillsnake 35 27.06.17 10:06 Сейчас в теме
про ситуацию с КД 3.0 - что мешало сделать интеграцию на КД 2.1 или файликами? Или это было дороже, чем внедрение новой программы и последующие её допилы? (105)

Причем тогда здесь 7.7 не позволяет провести интеграцию... )))))),


лио я не так объясняю либо вы чего о не понимате.

Есть большой завод АО . у них кд 3.0 все.

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

так люди теряют деньги оставаясь на 7,7 итд ...
109. d4rkmesa 27.06.17 12:08 Сейчас в теме
(108)
Ну, видимо выгоды особой не было от внедрения обмена через Enterprise Data в 7.7, хотя такие решения существуют, неужели никто не взялся?
110. hillsnake 35 27.06.17 19:18 Сейчас в теме
(109) представляю, что это за изврат.

да вообще там разговор короткий был, типа у вас КД3 нет, тогда до свидания.

прошли те времена когда можно было нанять девочку, чтоб вбивала данные с листа.
113. monkbest 115 28.06.17 13:34 Сейчас в теме
(110) да почему изврат? :)
в 7.7 есть поддержка XML, а КД 3.0 это не что иное как обычный обмен через XML с условием, что все имена тегов и атрибутов заранее определены. В теории можно на КД 2 написать обмен с некой конфигурацией по структуре равной формату Enterprise Data. Уверен, что это уже делали.
IvanovAV; +1 Ответить
115. AlexO 135 28.06.17 14:31 Сейчас в теме
(113) это невозможно хотя бы потому, что не все типы данных 7.7 конвертируются в текст, т.е. в пресловутый (и всеми, почему-то, любимый) XML.
Взять хотя бы периодический реквизит.
Вообще, у 1С изначально, что в 7-ках, что далее, неправильный подход к типам данных: вместо унификации и базировании на примитивных типах - постоянно ваяют новые и новые типы, что периодический реквизит в 7.7, что NULL-НЕОПРЕДЕЛЕНО в 8, не говоря уже про все эти бесконечные "Справочник.", "Документ.", "Регистр.".
у 1С даже типы регистров внутри 8-ок несовместимы между собой. А ведь изначально это - просто реляционные таблицы, только изуродованные до неузнаваемости.
120. nickperel 5 10.07.17 20:57 Сейчас в теме
(115)
Вообще, у 1С изначально, что в 7-ках, что далее, неправильный подход


Понятно с поциентом.
sashocq; red80; +2 Ответить
121. red80 27.09.17 14:10 Сейчас в теме
(115)
просто реляционные таблицы, только изуродованные до неузнаваемости
Если вас окружают бараны, возможно вы - главный. (Не мое)
116. Gluk_1C 28.06.17 14:33 Сейчас в теме
(110) Коллега давайте наверно подведем итог и прекратим флуд не по сабжу, слишком сильно в сторону ушли ))))
ИТОГ: В рамках приведения к однообразию было принято решение перейти на новый продукт, успешно внедренный в других подразделениях холдинга.
Техническая возможность/невозможность решения на 7.7 не причем, от слова совсем ))).
Dementor; hillsnake; +2 Ответить
103. 1cmax 152 25.06.17 01:13 Сейчас в теме
(87)
только вложено труда программиста и руководителей. В них идеальная автоматизация всех внутренних процессов. С ними жалко расставаться, получить современный аналог, столь же вылизанный и допиленный стоит очень больших денег.
База на 7.7 скорее всего живет более 15 лет, это значит, что как минимум бизнес успешно пережил все эти 15 лет. Все 15 лет в эту базу вкладывались денежки. даже если бюджеты были маленькие, за 15 лет это уже огого. И руководство и персонал уже привыкли к определенному уровню автоматизации и сде
Просто я давно придерживался правила, если управленческая система работает хорошо, её не надо трогать и переписывать. нужно адаптировать. ну речь не только о 7.7 скорее об ут 10.3. но в целом подход правильный, если что-то работает хорошо, не суй эту МЕГАУНИВЕРСАЛЬНУЮТИПОВУЮДЛЯВСЕХСТОРМОЗАМИОТ1с. У фирмы 1с свои цели, у бизнеса в конкретной ситуации - свои. Так что все относительно, в одной ситуации нужен новый продукт, в другой - старый друг лучше новых 2х.
IvanovAV; rovenko.n; monkbest; +3 Ответить
114. AlexO 135 28.06.17 14:23 Сейчас в теме
(87) Добавлю, что и подход совершенно разный - у 7.7 и 8.х.
Свобода и почти нативное программирование в 7.7 (т.е. если сравнивать именно сегмент 1С-продуктов), и рельсы, зажатость, и программирование через не то место в 8-ках.
Поэтому и живут 7.7-базы 15 и более лет, поэтому же и не хотят с ними расставаться. Минимум - ставят задачу получить такой же функционал.
А в рамках перехода с 7.7 на 8.х (и вообще у 1С) это невозможно.
5. genayo 10.06.17 07:35 Сейчас в теме
Как это все знакомо. Видимо, каждый франч должен пройти через такой проект...
stilet; 1СERP; +2 Ответить
6. CheBurator 3119 10.06.17 08:58 Сейчас в теме
Как все знакомо
Какое ТЗ пилить?
Подробное? На больших да и не очень проектах когда заказчик хочет точно знать что он получит и за что платит деньги - нереально составить ТЗ которое описывает готовый результат да ещё с такой степенью подробности - на одно составление такого тз уйдёт куча времени и денег. Составляя подробное тз ты сталкиваешься с задачами заказчика которые лежат на стыках подразделений - начинается либо тупняк либо отпихиваете и тихое подсылание нафиг со стороны заказчика. Вынесение таких вопросов наверх либо существенно тормозит процесс тз либо вопросы решаются командирским решением руководителей заказчика и такие решения частенько полумертвые
Писать тз на уровне функциональных требований - всегда есть разногласия причём существенные как кто эти требования понимает.
И все становится непонятно...
eeeio; graphbuh; +2 Ответить
7. baracuda 2 10.06.17 10:09 Сейчас в теме
Все прочитал с большим интересом.
Спасибо за цитату Джо Мараско, очень понравилась.
10. nickperel 5 10.06.17 13:46 Сейчас в теме
Очень длинно написал, простите.

Но вижу по другим обсуждениям здесь, что проблема ключевая. С поправкой - кто организует проект. Если такая структура, как "Раздолье", то бюджет большой.

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

Может есть способы мало затратной интеграции подрядчиков?
11. genayo 10.06.17 16:05 Сейчас в теме
(10) Проблема в том, что * получает руководство, а проблемы - ИТ служба. Понятно, что иногда у ИТ не выдерживают нервы :)
12. genayo 10.06.17 16:10 Сейчас в теме
(11) Фигассе, тут цензура чтоле? ***
artfa; корум; Paradise.87; +3 Ответить
13. RAV38574 119 10.06.17 18:09 Сейчас в теме
Всегда с клиентом обговариваю докручиваем типовой до ваших хотелок с минимальными изменениями, на с соглашениями, что всякие изменения типового обсуждается точно. Если сохранение типовой не важно, тогда свобода полная, но чтобы программист внес доп. поле не проанализировав что уже есть - это делитанство. Адекватный ИТ отдел кстати по моему опыту наоборот является аккумулятором хотелок и отсекает дурные идеи, что занимает много времени внедренца если он будет слушать эту чушь. Про ТЗ да сложно, да кропотливо, но на большой проект необходимость, иначе не оплата или неудовлетворенность клиента (меня развели на бабки)..
14. alex_sh2008 4 10.06.17 18:21 Сейчас в теме
Не понятно, почему вы вообще навязали клиенту УПП, ведь прекрасно понимали, что придется переписывать? Может из правила "втюхать, а потом хоть пожар"?
26. 1СERP 3045 13.06.17 12:23 Сейчас в теме
(14)
Цитата из статьи: "торговля + себестоимость + бюджетирование - означали УПП"
16. timeforlive 15 10.06.17 18:56 Сейчас в теме
хорошая статья, спасибо. Еще понравились иллюстрации, как раз в тему. Пора по 1С сделать аналогичные :)
АльфаАвтоПрограммист; +1 Ответить
17. Арчибальд 2706 11.06.17 23:10 Сейчас в теме
Довнедрение системы было поручено ИТ-службе, в итоге они ее постепенно довели до ума, и работают на ней до сих пор.
О как! По жизни, я так понимаю, если бы 20% бюджета заплатили упомянутым двум толковым сотрудникам ИТ, проект был бы не провальным, а вполне себе успешным. Это, собственно, иллюстрация к моему несостоявшемуся докладу на конференции Инфостарта. Причина провальных проектов (ну, процентов на 60) - привлечение "профессиональных" внедренцев.
Это сейчас уже понятно, зачем нужны интеграционные тесты, формализация требований к общим справочникам и так далее. Но в то время я просто решила набрать на проект побольше программистов

Классика. библия 50 лет назад было известно, что добавление программистов удлинняет процесс программирования. А теперь вдруг это опять открывают...
Респект автору за честность.
Артано; IvanovAV; AlexO; zqzq; mitia.mackarevich; +5 Ответить
22. CheBurator 3119 12.06.17 21:25 Сейчас в теме
(17) Арчи, собственники удавятся, но своему персоналу - лям не заплатят. заплатят на сторону.
graphbuh; Krasnyj; DarkUser; o.nikolaev; Lacrimosa0000; Бывалый77; smirnov.es; KapasMordorov; brr; +9 Ответить
27. 1СERP 3045 13.06.17 12:26 Сейчас в теме
(17)
"О как! По жизни, я так понимаю, если бы 20% бюджета заплатили упомянутым двум толковым сотрудникам ИТ, проект был бы не провальным, а вполне себе успешным. Это, собственно, иллюстрация к моему несостоявшемуся докладу на конференции Инфостарта. Причина провальных проектов (ну, процентов на 60) - привлечение "профессиональных" внедренцев."
- Не был бы. Переходить нужно было быстро, двумя людьми это сделать было невозможно.

"Классика. библия 50 лет назад было известно, что добавление программистов удлинняет процесс программирования. А теперь вдруг это опять открывают...
Респект автору за честность."
- Все читают теорию, но осознавать и использовать начинают после своих шишек. Об этом и пишет автор.
rovenko.n; +1 Ответить
40. nickperel 5 14.06.17 11:03 Сейчас в теме
(17)
О как! По жизни, я так понимаю, если бы 20% бюджета заплатили упомянутым двум толковым сотрудникам ИТ, проект был бы не провальным, а вполне себе успешным. Это, собственно, иллюстрация к моему несостоявшемуся докладу на конференции Инфостарта. Причина провальных проектов (ну, процентов на 60) - привлечение "профессиональных" внедренцев.


В статье описано, что ИТ - отдел молотил на 100500 процентов. Не помогло.
"Профессиональных" - имеется в виду, тех что соглашается по всем позициям с заказчиком и тонет в компромиссах? Или не выполняет обязательства? На что намек?
Что проект с ERP скорее всего не случиться, если привлечь кого-то со стороны? Это не так.
39. smirnov.es 21 14.06.17 09:55 Сейчас в теме
(22) Кстати да, руководителю департамента-заказчика, или ИТ-службы, всегда в разы проще выбить большой бюджет на подрядчика, чем на небольшое увеличение ФОТ для внутренних исполнителей. Много раз сталкивался с этим
55. Арчибальд 2706 15.06.17 19:39 Сейчас в теме
(22) Знаю, сам боролся. Но полляма обещали. Правда, заплатили все же 0.4
58. nickperel 5 19.06.17 10:13 Сейчас в теме
(55)
Знаю, сам боролся. Но полляма обещали. Правда, заплатили все же 0.4


Я все время пытаюсь это предлагать заказчику. Когда получается, все идет очень энергично.
У вас получилось с внедрением?
18. user770267 11.06.17 23:15 Сейчас в теме
. Кому принадлежит проект?

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

Решение:
Убедитесь, что у вас есть поддержка высшего руководства. Должна быть прямая связь между топ-менеджерами компании и акционерами вашего бизнеса. Ключевое сообщение должно быть таким: «это произойдет, так что вы либо с нами, либо без нас» и убедитесь, что они не выберут второй вариант.
Как менеджер проекта, будьте внимательными, чтобы топ-менеджер не принял управление проектом на себя и не стал фактически руководителем проекта.
Lacrimosa0000; KazanKokos; baracuda; +3 Ответить
28. 1СERP 3045 13.06.17 12:27 Сейчас в теме
(18)
В данном проекте один из собственников бизнеса - был куратором проекта и активно в нем участвовал.
19. user770267 11.06.17 23:15 Сейчас в теме
2. Привлекайте пользователей

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

Решение:
ИТ-департаменту нужно время чтобы понять требования клиентов прежде чем предлагать любое техническое решение. Часто ИТ-департаменты ослеплены последними, самыми новыми информационными продуктами и стараются подогнать существующие требования под них. С другой стороны, для успешной реализации проекта клиенты должны выделить некоторое время и совместно с ИТ-отделом убедится, что все их требования были полностью обозначены. Удостоверьтесь в том, что вы поговорили со всеми акционерами компании и учли их требования, и в том, что они поддержат Вас на протяжении всего проекта.
Olenevod; +1 Ответить
29. 1СERP 3045 13.06.17 12:28 Сейчас в теме
20. user770267 11.06.17 23:16 Сейчас в теме
Остановите расползание масштабов проекта

Ошибка:
Увеличение масштаба проекта – одна из основных причин неудач. Не знание точных итоговых целей проекта или потворство своим порывам энтузиазма – рецепт неудачного проекта.

Решение:
Убедитесь, что бизнес-план, требования и рамки проекта четко определены и задокументированы. Акционеры компании поняли их и поставили на них свою подпись. Жестко придерживайтесь установленного объема проекта и, если необходимо внести изменения, проведите их через процесс управления изменениями, где они будут задокументированы, будет подтверждена их правомерность и они будут утверждены.
30. 1СERP 3045 13.06.17 12:29 Сейчас в теме
(20)
Так одной из ключевых проблем этого проекта было то, что границы определила ИТ-служба. Границы были. Позже оказалось, что то, что получалось "в границах" бизнесу было не нужно.
21. gubanoff 63 12.06.17 13:25 Сейчас в теме
(0) Картинки я бы убрал, отвлекают
DarkUser; sashocq; li5enok; olegmedvedev; Paradise.87; +5 Ответить
31. 1СERP 3045 13.06.17 12:30 Сейчас в теме
(21)
Выше был положительный отзыв о картинках. Так что пока 1:1
32. brr 182 13.06.17 13:22 Сейчас в теме
В первый же день прилетела вторая «атомная бомба»: как оказалось, выделенные в апреле ключевые пользователи тоже не владели полной информацией: были люди (а иногда и целые отделы), которые работали «чуть-чуть по-другому».


Это классика внедрения, при опросе руководителей и исполнителей, какие функции выполняют исполнители, списки функций не совпадают :)
1СERP; sunrise2506; +2 Ответить
36. Temir_S 22 14.06.17 08:50 Сейчас в теме
(32) увы, зачастую даже то что "говорят" исполнители и то что они "делают" на самом деле, тоже не совпадает. На моей практике они "забывают" о чем-то сообщить, нередко это ключевая их функция с точки зрения автоматизации.
sashocq; rovenko.n; +2 Ответить
37. rovenko.n 14.06.17 09:27 Сейчас в теме
(32)Согласен, на практике была ситуация, когда неделю прописывали схемы процессов с руководством, а потом пришел работник, который будет работать с этой системой. И сказал, что он физически не успеет всё делать, потому что при текущей нагрузке он выдает печатные документы работникам в течение двух часов (а надо за полчаса), а при доработке количество кликов увеличивается больше чем в два раза.
38. rovenko.n 14.06.17 09:32 Сейчас в теме
(36)Требуйте подписания ТЗ не только руководителями, но и участниками рабочих групп. Когда будущие пользователи видят, что под документом будет стоять ИХ подпись, сразу же начинают вспоминать больше, начинают вчитываться в ТЗ и давать комментарии (и количество неучтенных моментов сильно уменьшается).
vadeem_13; 1cmax; АльфаАвтоПрограммист; 1СERP; +4 Ответить
41. brr 182 14.06.17 11:15 Сейчас в теме
(36) Согласен, опрос это только первый этап. Потом еще и собственное исследование бизнес- процессов нужно делать.
45. nickperel 5 14.06.17 11:52 Сейчас в теме
(41)
собственное исследование бизнес- процессов

а если это производство, то ВНЕЗАПНО придется составить представление о технологии и предметной области.
47. Temir_S 22 14.06.17 13:53 Сейчас в теме
(38) требовала, обвинили в бюрократии :)
Требовала и когда работала со стороны ИТ заказчика и много позже, когда стала работать на стороне исполнителя. Помогает конечно, но не панацея.

По моему опыту залог успешного внедрения это вовлеченный ответственный пользователь и вовлеченный же представитель заказчика (руководитель) с административным ресурсом. С этой парой можно горы перевернуть. Даже преодолеть молчаливое сопротивление ИТ службы заказчика. Отсутствие заинтересованности одного из них сильно усложняет процесс внедрения, а обоих делает его заведомо неудачным. Для меня самый провальный был проект в котором внедрили, работало, приняли, но продолжили работать в ексель... "потому что привыкли и так проще". Внедряли Документооборот Корп.
sergeyap; Krasnyj; Winstoncuk; 1cmax; 1СERP; +5 Ответить
59. nickperel 5 19.06.17 10:29 Сейчас в теме
(38)
Требуйте подписания ТЗ не только руководителями, но и участниками рабочих групп. Когда будущие пользователи видят, что под документом будет стоять ИХ подпись


Сценарий - они отказались, директор не настаивает и сам все подписал. Предложил не приставать к его людям и начинать уже работать. Людей указал, доп. оплату им зарубил, от основных обязанностей не освободил даже частично.
И как? Отказаться от проекта, если он сложный?
48. rovenko.n 14.06.17 15:24 Сейчас в теме
(47)"потому что так привычнее" - и не говорите, часто бывает. Внедрили на предприятии автоматизированную систему, но сотрудники "старой закалки" продолжают писать проводки вручную на бумаге карандашиком.
Просто РП должен изначально указать, что подписывать ТЗ должны его потребители. А потребителем выступает будущий пользователь, а не руководитель Заказчика. Руководителю абсолютно неважно какие кнопочки будут на формочках и документах.
60. nickperel 5 19.06.17 10:44 Сейчас в теме
(47)
Для меня самый провальный был проект в котором внедрили, работало, приняли, но продолжили работать в ексель... "потому что привыкли и так проще". Внедряли Документооборот Корп.

С любым документоводом так, не только с 1с. Лечится только принудительно - административной загрузкой всех файлов в инф.базу и почтовыми учетками. Потом бакап и закрытие шары "Общая папка".
Причем грузить надо все, включая mp3 и джипеги с корпоративов. Только сами владельцы файлов могут что-то там рассортировать.
62. rovenko.n 19.06.17 10:46 Сейчас в теме
(59)
- они отказались, директор не настаивает и сам все подписал. Предложил не приставать к его людям и начинать уж

Неправильный директор. Дело не в отказе от проекта. Просто это один из самых больших "рисков", который потом обязательно вылезет боком.
61. nickperel 5 19.06.17 10:46 Сейчас в теме
(48)
Руководителю абсолютно неважно какие кнопочки

Важно ему это. Ему нужно, чтобы те что с карандашиком и проводками сообщили ему, что они теперь пишут проводки в программе.
63. nickperel 5 19.06.17 10:52 Сейчас в теме
(62)
Неправильный директор. Дело не в отказе от проекта. Просто это один из самых больших "рисков", который потом обязательно вылезет боком.

Все директора так или иначе "неправильные". У "правильных", как правило, все и так работает.

Тут даже не риск. Нельзя работать без принятых результатов, будет платежный дефолт. А работать надо, вот и пишем ноу-хавы.
65. Temir_S 22 19.06.17 11:02 Сейчас в теме
(60)у меня было острое желание снести эксель :)
67. rovenko.n 19.06.17 11:25 Сейчас в теме
(61)нет, нет. Не путайте, руководителю важен результат - отчет по закупкам/ продажам, бюджеты, проводки и прочее. Всякие "создать на основании", "заполнить по данным", галочки руководителю глубоко безразличны. Ему эти удобства ни к чему.
68. rovenko.n 19.06.17 11:26 Сейчас в теме
(63)именно. пишем, а потом оттачиваем, хотя можно было написать с первого раза.
79. nickperel 5 21.06.17 18:03 Сейчас в теме
(67)
нет, нет. Не путайте, руководителю важен результат

Где я путаю? Написал - директор проверит информацию у своих.
Они скажут ему буквально - "стало невозможно работать, это какой-то кошмар.." и вы тоже начнете думать "про галочки".
102. 1cmax 152 25.06.17 00:59 Сейчас в теме
(60) 1с документооборот это рак, все разговоры внедренцев о том, как мы настраивали права в документообороте.
117. AlexO 135 28.06.17 14:42 Сейчас в теме
(60)
Лечится только принудительно - административной загрузкой всех файлов в инф.базу и почтовыми учетками. Потом бекап и закрытие шары "Общая папка".
Причем грузить надо все, включая mp3 и джипеги с корпоративов.

Ну попробуйте загрузить 50-100 Гб подобного "информационного мусора" в 1С - и получите полностью нерабочую по причине тормозов базу.
Только Oracle-SQL, только нормализованные таблицы.
90% всех данных - это архивные данные, становящиеся таковыми либо сразу при создании, либо - спустя какое-то время.
И общую базу всех "шар" делают не для того, чтобы постоянно там чего-то лопатить, а чтобы можно было делать централизованный бекап, т.е чтобы данные не потерялись.
А пользоваться ими могут и раз в сто лет.
119. nickperel 5 10.07.17 20:56 Сейчас в теме
(117)
Ну попробуйте загрузить 50-100 Гб подобного "информационного мусора" в 1С - и получите полностью нерабочую по причине тормозов базу.
Только Oracle-SQL, только нормализованные таблицы.
90% всех данных - это архивные данные, становящиеся таковыми либо сразу при создании, либо - спустя какое-то время.
И общую базу всех "шар" делают не для того, чтобы постоянно там чего-то лопатить, а чтобы можно было делать централизованный бекап, т.е чтобы данные не потерялись.
А пользоваться ими могут и раз в сто лет.


1. грузил. рабочая. а ты?
2. без разницы. ты недавно прочитал про нормализацию?
3. я знаю что и кому нужно на шарах и сколько там лежит и чего. уже лет 20 как в курсе.
пиши еще
101. 1cmax 152 25.06.17 00:41 Сейчас в теме
(47)
Внедряли
Заинтересованный ответственный пользователь, это залог успеха, правда.
164. vadeem_13 30.09.17 15:17 Сейчас в теме
(45) И вот тут ты становишься тем самым загадочным "Программистом 1С" ... :)
33. solodovnikov.84 11 13.06.17 20:52 Сейчас в теме
Как часто такое приходиться встречать.Хуже наверное только бывает,когда твой руководитель согласовывает то,что сам не понимает.Или оценку делает.Или когда желания клиента многократно превосходит его финансовые возможности.А сейчас стало модно играть конкурсы.Где ТЗ от клиента его желаний это бред сумасшедшего. Или проще,копирование описаний конфигураций с сайта 1с.А когда выигрываешь.Начинаешь разбираться,а оказывается нужно совсем другое.И намного дороже.Клиент в 99% сам не знает до конца,что он хочет.И после такого работать не хочется.Чувствуешь себя идиотом.Что скажешь "что в ТЗ то и сделаю?".После этого тебе точно спасибо не скажут.Порой,что бы что то внедрить уходит несколько недель понятия учета и принципа работы организации.В этом плане работы по 1с по мне так очень сильно спешат.Всегда очень маленькие сроки.После последней оценки переноса из сторонней программы в 1с моим руководителем при которой я пол месяца проработал бесплатно.Спасая честь нашей организация.Потому что он ее даже не открыл.Я ушел.Честно говоря,учет и программы становятся сложнее и работы,которые требуются от компаний франч стали дороже.Сейчас проще держать своего под боком.Сидел бы он в организации и пилил бы код.А не бежал бы после обеда ко второму клиенту.Статья действительно полезная.Приятно понимать,что не только ты один в таком бывал.Самое главное опыт чужой.Лишний раз убеждаешься.Что перед работой,нужно пройтись по всем пунктам,людям и задачам.Так что спасибо!
Olenevod; o.nikolaev; Gluk_1C; Dementor; rovenko.n; 1СERP; +6 Ответить
43. nickperel 5 14.06.17 11:41 Сейчас в теме
(33)
Как часто такое приходиться встречать.Хуже наверное только бывает,когда твой руководитель согласовывает то,что сам не понимает.


Такое с обеих сторон. Что у такого руководителя в отделе на фикси, что у такого франча ничего не сделаешь, не сдашь и не заработаешь. Хоть и говорят о полезности компромиссов, но работать бесплатно не допустимо.
34. Samson-lim 13.06.17 20:52 Сейчас в теме
Пару приемов на данную тему: Все из опыта.

Описание предметной области:
Проекты от 1000 часов и выше.
Внедрение типовых продуктов с доработкой. Считаю, что разработка с "0" - отдельная тема в ней не разбираюсь.
Говорю на своем опыте.
Ни с кем не спорю.

Команда проекта:
============================================================­=
1. Обязательно: РП Заказчика и РП Исполнителя. По договору РП Исполнителя должен быть главным (даже если в жизни не получится)
2. Обязательно: Кураторство проекта со стороны ТОП-менеджмента компании Заказчика. Кураторы в проекте участие принимать не будут, но туда мы будем бегать жаловаться и запихивать наши бумажки.
3. Обязательно: РП Заказчика не может являться программистом 1С. Он такая же рабочая лошадка РП со стороны Исполнителя. Он управляется ранее подписанными им бумажками. Я предпочитаю с ними дружить.
4. Обязательно: РП Заказчика должен быть функциональным заказчиком - чем выше тем лучше.
5. РП Исполнителя работает с бумажками и деньгами. Если он является хорошим коммуникатором (его все понимают), то еще отвечает за этот аспект. Не более. Архитектура - к архитектору, методология - к методисту. РП не использовать вообще, ни при каких обстоятельствах. РП согласовывает решения и бюджеты.
6. Обязательно: Кураторы со стороны Исполнителя, туда мы идем для того, что бы РП проверили по перечню подготовленных документов. И принесенных денег.


Техническое задание
============================================================­=
Исхожу из принципа, что детальное техническое задание на систему типа ERP/УПП/ Управление холдингом или более менее крупную УТ - физически не возможно (Из этого правила нет исключений в моем опыте)

Видел большое количество ТЗ и своих и очень крупных 1С франчайзи и SAP и Nav, короче вне зависимости от продукта или компании). Красивые документы делать делают, но в лучшем случае там только концепты решений. Концепты нужны обязательны. Лучше если Ваши сотрудники внутри проектной команды будут общаться через бумажку в виде конецпта.

Поэтому с рамками работаю так:
1. Рамки договора - в нем детальное блоки / и насколько возможно детальные функциональные рамки (названия функций).
2. Блоки как можно меньше, но не менее 100 000 - 150 000 рублей.

2. Дальше сразу демонстрация типового функционала. Даже если клиент говорит, что давайте сначала я расскажу, что хочу. РП долже ему объяснить, что клиент уже сделал выбор конкретного решения и хотеть он будет в его рамках.

Демонстрации проводим сначала внутри проектной команды (ключевые пользователи, РП со стороны заказчика), потом включая пользователей на местах:
1. Начинаем с перечня в договоре: Перечень внедряемых блоков -> Перечень внедряемых функций. Перечень функций постоянно уточняем. Его я расширяю почти без ограничений (кроме ситуаций с интеграциями). Ни в коем случае не добавляем блоки. Добавление происходит только через изменение рамок договора и дополнительный бюджет. При этом нужно выделять найденные функции в отдельные блоки, информировать Заказчика об их появлении, но добавлять в проект, как писал выше, через договор.
2. Демонстрация типового функционала по перечню внедряемых блоков по перечню внедряемых функций.
3. Протоколы демонстраций и протоколы замечаний к демонстрации. Протокол демонстрации нужен для того, что бы написать что Вы показывали клиенту. А протокол замечаний, что бы он написал, с чем он не согласен. Остальное принимается в Базе. Далее эти бумаги и используем в качестве ТЗ. Можем оформлять, если требуется.
4. Устранение замечаний по протоколу замечаний к демонстрации (тут много вариаций, смотря как вы работаете с бюджетом)

Повторяем, пока всем не надоест.
=======================================

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

Опять цикл:
=========================================
1. Прогон внутри проектной команды (ключевые пользователи, РП со стороны заказчика)
2. Протокол замечаний к демонстрации
3. Устранение замечаний по протоколу замечаний к демонстрации (тут много вариаций, смотря как вы работаете с бюджетом)
4. Цель: Команда проекта со стороны заказчика должна наизусть знать этот пример, и официальный прогон должен стать "перерезанием красной ленточки".

Выход из цикла, когда всем надоест.
=======================================

Промышленная эксплуатация - просто сервис - классика 1С:Франчайзинга - ни чего не придумываем. Обязательно за объем бюджета не вошедший в первоначальный договор или бюджет в нем зафиксированный - как отдельный бюджет на данный этап.

Прочий проектный документооборот:
=======================================
Море, море составленных бумажек. Чем больше тем лучше. Везде подпись клиента. Печати не обязательно (хотя 1С и требует), все это нужно, что бы не идти в суд. При походе в суд, это тоже сильно поможет.

Деньги:
=======================================
Деньги всегда вперед. К моменту передачи проекта заказчику 80% бюджета в деньгах должно быть у Вас.

Прочее:
=======================================
Желательно, что бы до момента, пока вы не получили с клиента 100% денег весь софт должен находиться на вашей территории, а лучше всего, что бы клиент и работал на Ваших серверах. Но это получается не всегда.
vadeem_13; zqzq; Vladimir Litvinenko; Vyatcheslav; корум; i_lo; Arrigo; Dementor; 1СERP; Светлый ум; solodovnikov.84; +11 Ответить
35. monkbest 115 14.06.17 08:32 Сейчас в теме
Фига провальный проект :)
Единственный провал - отсутствие хорошего отзыва :)

Клиент все оплатил, включая переработки => прибыль получена. Для раздолья проект успешный, УПП втюхано, доход получен. Если бы было озвучено, что мы отработали 2000 часов, а нам заплатили за 1000, то да, грусть тоска.
Gureev; wazup666; AlexO; Lacrimosa0000; Hans; artfa; rovenko.n; +7 Ответить
42. 1СERP 3045 14.06.17 11:24 Сейчас в теме
(35)
Ну... перерасход бюджета там был приличный. Клиент остался недовольный. Это и есть неспешный проект.
44. nickperel 5 14.06.17 11:49 Сейчас в теме
(35)
УПП втюхано, доход получен.

Деньги идут от живущего проекта, а не коробки. Втюхивать надо лабутены дамам. Это продуктивнее.
53. monkbest 115 15.06.17 12:59 Сейчас в теме
(42) из статьи следует, что недовольство было из-за увеличения сроков и бюджета, а также из-за обманутых ожиданий от внедрения. Т.е. не внедренец пострадал, получив первоначально оговоренные деньги и потратив больше часов, а заказчик, оплатив изначально оговоренное и дополнительные работы.
У меня было несколько опытов перерасхода, но пострадал исполнитель (я), не получив прибыль с проекта. А вот заказчик был доволен, хоть и были сорваны все сроки, он получил систему удовлетворяющую ожидания.

Тут, как и почти всегда, проблема в продажниках, продавших не то не туда. А дальше у каждого своя дорожка:
1. отменить проект и разбежаться с минимальными потерями, сразу как только пришло понимание, что мы занимаемся чем-то не тем. (все расстроились)
2. внедрять до победного, за оговоренные ранее деньги (заказчик рад, исполнитель расстроился)
3. внедрять ровно то, что оговорили согласно ТЗ и трясти деньги на допы (заказчик расстроился, мы рады, но делаем вид, что расстроились)
54. monkbest 115 15.06.17 13:03 Сейчас в теме
(44) стоимость УПП не маленькая, а маржа франча примерно половина. в зависимости от статуса. Плюс есть такая штука как показатели работы, которые надо выполнять, чтобы быть центром компетенции по производству надо было вывешивать на сайте как много УПП мы внедрили, причем в терминах 1С продажа + бумажка с отзывом = внедрение.
Т.е. стоит у Вас задача стать ЦКП и Вы ориентируете своих продажников на втюхивание УПП, а не УТ, которое как писала девушка было бы логичнее.
57. nickperel 5 19.06.17 09:59 Сейчас в теме
(54)
+ бумажка с отзывом = внедрение.
Т.е. стоит у Вас задача стать ЦКП и Вы ориентируете своих продажников на втюхивание УПП, а не УТ, которое как писала девушка было бы логичнее.


Вы приписали свои мысли мне и с ними спорите. Все правильно, так сейчас и принято.
Я не продаю, партнер продает. Я - только разработка и внедрение.

А "втюхать", еще раз, не получиться у вас ничего. ЦКП или не ЦКП, без разницы. Что УТ, что УПП потом надо внедрять. Иногда это сложно. Вот про это этот тред.

И да, я часто, бывает слышу критиков вроде вас, которые комментируют посторонние им проекты в определениях "они втюхать хотят". Это как минимум безответственно, потому что заочно. Как минимум..

После рекомендаций иксперта вроде вас, иногда остаются конторы, например, с УТ и десятком баз БП. Попытка потом собрать общую упраленческую\неуправленческую отчетность сколько будет стоить? Объединение справочников? Не 150 тысяч, примерно на круг? И без разницы есть или нет производство.

А сколько стоит УПП в случае УТ + 10 х БП уже без разницы. Здравый смысл проехали на прошлой станции. "Маржа франча" - не то же что и бонус с продаж менеджера.

И да, 1С собирает "бумажки" о продажах, которые внедрения. И о внедрениях, которые продажа. А что их не надо собирать? И за всей информацией покупателя адресовать в трэды на мисте?
Правильно, нет?
Gluk_1C; Dementor; rovenko.n; +3 Ответить
64. Temir_S 22 19.06.17 10:53 Сейчас в теме
(53) возможно, не могу сказать за автора. Но я увидела немного другое. В такой ситуации страдают все и внедренец и заказчик. Не все же меряется полученной прибылью и произведенными расходами. Я вижу недовольство собой, признание того, что неправильно оценила ситуацию. Да. согласна, очень часто продажники продают не то и не тем, но ведь когда я прихожу на проект, я должна его оценить на жизнеспособность. Увидеть и предотвратить какие-то проблемы. Естественно не все, но уж точно больше, чем может увидеть продажник. И вот тогда, на начальном этапе, проговорить эти проблемы и может даже прервать проект. Мне кажется это немного об этом.
Очень уважаю автора за мужество признаться в своих ошибках, в первую очередь себе. На мой взгляд, это очень ценно. И уж в вдвойне - признаться публично.
Спасибо автору, что поделились таким опытом.
Оставьте свое сообщение