Лучшие комментарии
Остальные комментарии
Избранное
Подписка
Сортировка:
Древо
Начать внедрение и не зайти перед этим в бухгалтерию - не по-христиански это как-то...
Mails79; Александр4023512; Ioryk; утюгчеловек; rmIvanT; e9953; xantif_2000; sevushka; tricolor; AllexSoft; Nehc; Олег Ящеров; user767626; smit1c; o.nikolaev; elzetto; Созинов; maksa2005; webester; bulpi; Sergik_D; Robbi; Red1; AlenaR; Алексей_mir2mb; Iraida_1964; BigB; jig; Sintson; IssakN; user635667; user811769; Anchoret; akim2040; kiruha; arakelyan; artms; chebser; Азверин; acanta;
+40
–
Ответить
Руководство пусть и адекватные, но рыба гниёт с головы.
Многие вопросы должны были решаться раз и навсегда.
Но, спасибо. Где-то уловил знакомые ситуации, что-то новое.
Многие вопросы должны были решаться раз и навсегда.
Но, спасибо. Где-то уловил знакомые ситуации, что-то новое.
Ошибка 1.
Не исследовали персонал досконально(биг-дата же рулит, нэ?) и не соблюли "церемониал".
В серьезных конторах даже просто беседа и чаепития входят в обязательные
процедуры расстановки приоритетов .
Игнор главбуха на старте - непростительная оплошность, особенно в политическом плане.
Обделенная вниманием, простите баба, с наделенными полномочиями обязательно
станет в позицию "начточу я свой топор..." и отобрать у нее этот топор будет сложно и
только в случае грамотно проведенных "церемониалов".
Если главбух не стал союзником, а стал врагом - это очень плохо.
Ошибка 2.
по фразе
понятно, что разработчик пошел по скользкой дорожке гнобления экселя и его адептов:
отдел продаж, аналитики, логисты и т.п.
Важно понимать, что никакая 1С, даже 1С: 100500.10.20 во многих областях учета и рядом не стояла с возможностями эксель и те кто это постиг - будут упираться всеми чреслами если у них отберут аналитику в эксель.
Грамотных и опытных адептов экселя необходимо хвалить и лелеять ибо они выполняют ту работу которую 1С не сделает.
Важно сделать этих адептов союзниками.
По факту они стали врагами.
Ошибка 3. бесконечная "Попытка закрыть январь"
Вместо этой задачи, логичнее было тратить время с самого начала на разработку, уточнее и утверждение бизнес-процессов с четкой расстановкой "кураторов"
от руководства.
Не исследовали персонал досконально(биг-дата же рулит, нэ?) и не соблюли "церемониал".
В серьезных конторах даже просто беседа и чаепития входят в обязательные
процедуры расстановки приоритетов .
Игнор главбуха на старте - непростительная оплошность, особенно в политическом плане.
Обделенная вниманием, простите баба, с наделенными полномочиями обязательно
станет в позицию "начточу я свой топор..." и отобрать у нее этот топор будет сложно и
только в случае грамотно проведенных "церемониалов".
Если главбух не стал союзником, а стал врагом - это очень плохо.
Ошибка 2.
по фразе
не успело за 4 года отбросить ненужный эксель
понятно, что разработчик пошел по скользкой дорожке гнобления экселя и его адептов:
отдел продаж, аналитики, логисты и т.п.
Важно понимать, что никакая 1С, даже 1С: 100500.10.20 во многих областях учета и рядом не стояла с возможностями эксель и те кто это постиг - будут упираться всеми чреслами если у них отберут аналитику в эксель.
Грамотных и опытных адептов экселя необходимо хвалить и лелеять ибо они выполняют ту работу которую 1С не сделает.
Важно сделать этих адептов союзниками.
По факту они стали врагами.
Ошибка 3. бесконечная "Попытка закрыть январь"
Вместо этой задачи, логичнее было тратить время с самого начала на разработку, уточнее и утверждение бизнес-процессов с четкой расстановкой "кураторов"
от руководства.
(3)
С первой частью про Эксель - абсолютно согласен, плюсану.
А вот по поводу "закрыть январь"... Блин, это реально важно. По мне, так пока "январь не закрыт" - в топку все доработки под БП отличные от типовой! нужно что бы работал типовой функционал, а дальше уже под заказчика. Как там у автора в первом пункте - сначала бухучет, потом все остальное.
Ошибка 3. бесконечная "Попытка закрыть январь"
Вместо этой задачи, логичнее было тратить время с самого начала на разработку, уточнее и утверждение бизнес-процессов с четкой расстановкой "кураторов"
Вместо этой задачи, логичнее было тратить время с самого начала на разработку, уточнее и утверждение бизнес-процессов с четкой расстановкой "кураторов"
С первой частью про Эксель - абсолютно согласен, плюсану.
А вот по поводу "закрыть январь"... Блин, это реально важно. По мне, так пока "январь не закрыт" - в топку все доработки под БП отличные от типовой! нужно что бы работал типовой функционал, а дальше уже под заказчика. Как там у автора в первом пункте - сначала бухучет, потом все остальное.
Автоматизируя бардак, невозможно получить порядок - получится автоматизированный бардак.
Yaroslav1C; Vova_Di; FuNNyHoRRoR; artfa; Alexsur; AllexSoft; yurikmellon; EVKash; Nehc; s_a_r_u_m_a_n; o.nikolaev; Zircool; elzetto; Созинов; maksa2005; Serg O.; Rain88; webester; bulpi; Sergik_D; Robbi; Tarlich; Kaspirovsky; shard; Iraida_1964; Sintson; fancy; Summer_13; jif; mifka186; andreosh; dock; vdscom; obsfromekb; arakelyan;
+35
–
Ответить
Похоже запуск космического корабля без предварительных испытаний комплектующих
Изначально бы обследовал и внедрял бухгалтерию и смотрел бы на остальное. Когда закрыл бы, видел бы что твориться у остальных и смог бы оценить трудозатраты внедрения. Сведение данных по складу не ваш вопрос, не ясно почему вы им занимались.
Конечно всего не предусмотришь.
Изначально бы обследовал и внедрял бухгалтерию и смотрел бы на остальное. Когда закрыл бы, видел бы что твориться у остальных и смог бы оценить трудозатраты внедрения. Сведение данных по складу не ваш вопрос, не ясно почему вы им занимались.
Конечно всего не предусмотришь.
Поддержку коллег насчет главбуха. Воевать с ним такое себе. Надо стараться найти общий язык. Иначе есть риск провала проекта.
Директор может выписать п*й буху, но от этого крепче Ваша дружба со счетоводами вряд ли станет.
У Вас же результат принятия Вашей работы заказчиком зависит от бухгалтерии. Директор склонен доверять бухгалтеру, а не Вам, как правило.
Ну и я проследил такие ноты, что проект внедрения КА был для Вас первым таким опытом. Т.е. в процессе Вы учились на клиенте. А оплата по факту принятия всех работ. Это все обуславливает высокий риск проигрыша. Оно не стоило 1000 часов как мне кажется. Жаль, что Вы столько потеряли.
Директор может выписать п*й буху, но от этого крепче Ваша дружба со счетоводами вряд ли станет.
У Вас же результат принятия Вашей работы заказчиком зависит от бухгалтерии. Директор склонен доверять бухгалтеру, а не Вам, как правило.
Ну и я проследил такие ноты, что проект внедрения КА был для Вас первым таким опытом. Т.е. в процессе Вы учились на клиенте. А оплата по факту принятия всех работ. Это все обуславливает высокий риск проигрыша. Оно не стоило 1000 часов как мне кажется. Жаль, что Вы столько потеряли.
На одном проекте с начало зашли в бухгалтерию. И выяснилось что собственник компании заключил с нами договор от юр лица с долгами перед бюджетом в десятки миллионов рублей.... Продолжать не стали.
Я технарь, не программист 1С и не внедренец, но было очень интересно читать. Жду продолжения/дополнения от вашего консультанта.
Жаль что у вас так получилось, но, как говорится: "Опыт - самый хороший учитель. Берет правда дорого, зато объясняет доходчиво".
Жаль что у вас так получилось, но, как говорится: "Опыт - самый хороший учитель. Берет правда дорого, зато объясняет доходчиво".
Сторонний специалист полностью перенастраивает настройки информационной базы, пытается настроить финансовый учет и закрыть январь. Безрезультатно. Показав полную профнепригодность и отсутствие каких-то результатов за полтора месяца, с позором прогоняется.
Корректируем начальные остатки (заново), начинаем подозревать отсутствие адекватного учета в Бух. базе.
Штатный консультант заново восстанавливает настройки. Программистам прилетает куча задач по восстановлению учета из-за измененных настроек - скрытые и неправильно заполненные реквизиты никто не отменял.
Корректируем начальные остатки (заново), начинаем подозревать отсутствие адекватного учета в Бух. базе.
Штатный консультант заново восстанавливает настройки. Программистам прилетает куча задач по восстановлению учета из-за измененных настроек - скрытые и неправильно заполненные реквизиты никто не отменял.
Отличная идея, кстати - менять настройки сразу в рабочей базе, да еще и не проверенным человеком. Ни в коем случае не надо этого делать на тестовых базах - нет.
(122) Ну, по-памяти:
Мышей достало, что их едят все кому ни лень. И решили они спросить совета у Мудрой Совы (уже смешно).
- Мудрая Сова, мы легкая добыча для любого зверья в этом лесу. Совсем житья нет. Как нам быть?
- Сова подумала-подумала и говорит - станьте ежиками! Тогда у вас будут иголки и вы перестанете быть легкой добычей.
Обрадовались мыши, бегут обратно и скандируют "станем ежиками! станем ежиками!". И тут самая умная мышь говорит
- Стоп! А как мы станем ежиками?
Побежали мыши обратно к Мудрой Сове:
- Мудрая Сова, а как нам стать ежиками?
- Я не тактик. Я стратег.
Мышей достало, что их едят все кому ни лень. И решили они спросить совета у Мудрой Совы (уже смешно).
- Мудрая Сова, мы легкая добыча для любого зверья в этом лесу. Совсем житья нет. Как нам быть?
- Сова подумала-подумала и говорит - станьте ежиками! Тогда у вас будут иголки и вы перестанете быть легкой добычей.
Обрадовались мыши, бегут обратно и скандируют "станем ежиками! станем ежиками!". И тут самая умная мышь говорит
- Стоп! А как мы станем ежиками?
Побежали мыши обратно к Мудрой Сове:
- Мудрая Сова, а как нам стать ежиками?
- Я не тактик. Я стратег.
Один из выходов - это писать дополнение к должностным инструкциям на каждое рабочее место. Затем писать кляузы: нарушен такой-то пункт инструкции. В реальности приходится программировать не только процесс учета, но и сотрудников, которые этот процесс должны вести. Если мне удается получить доступ к руководителю, который более остальных мотивирован на наведение порядка, то остальных я могу в бараний рог свернуть должностными инструкциями. Но в реале мне приходится внедрять систему, не имея доступа к руководителю. Этот доступ жестко охраняется его окружением. Потому на маневры уходит масса времени. А проблемы подобные, каждый прикрывает свои косяки и желает укоротить технологический процесс внедрения системы, вводя в систему кривые данные.
Комплексная это в принципе плохо. Бухгалтерия отдельно, упр учет отдельно.
Ну а так что сказать можно. Надо ставить порог дебиторки, точно так же, как наши клиенты ставят своим покупателям. Для меня это часов 15-20. Клиент интересен платежкой в первую очередь.
Ну а так что сказать можно. Надо ставить порог дебиторки, точно так же, как наши клиенты ставят своим покупателям. Для меня это часов 15-20. Клиент интересен платежкой в первую очередь.
(47) я до сих пор (а я довольно давно с этим работаю) видел одну (ОДНУ) компанию, в которой упр и бух учеты совпадали.
Поэтому сначала делаем упр так, как хотят хозяева, потом переносим в БП то, что хотят бухгалтеры. Все довольны.
Поэтому сначала делаем упр так, как хотят хозяева, потом переносим в БП то, что хотят бухгалтеры. Все довольны.
Очень сложно все взвесить и принять правильные решения по внедрению (делать или не делать и если делать то как, что и когда). Даже несколько успешных проектов не гарантируют от провала в будущем. Каждая организация - своя среда, обстановка, люди, процессы. И проблемы как раз возникают там, где не ожидаешь.
По вариантам, которые желательно было бы рассмотреть и придумать другие решения::
- оставить бухгалтерию как есть, настроить обмен с КА
- по номенклатуре и другой НСИ: нужно определить главную базу для создания/ведения НСИ, приоритет должен в любом случае быть по базам
- "Консультант воюет с настройками базы, возвращает в исходное состояние измененные главным бухгалтером настройки по фин. результату, настраивает бухгалтерский учет" - первоначальные настройки должны быть согласованы и зафиксированы, и желательно не допускать изменять даже главбуху, который, судя по рассказу, не совсем понимал что делал.
- результаты инвентаризации должны принести результат, если не принесли, значит что-то не сделали/ не смогли зафиксировать
- "возможность выбора организации в каждой строке авансового отчета" - вариант решения: создание рабочего места или мастер-документа для возможности создания нескольких авансовых отчетов по нескольким организациям в автоматическом режиме. Но никак не изменения типовых документов, которые участвуют в многих механизмах расчета.
По скрытым подводным камням, исходя из написанного:
Главбух очень странно себя повел, сам должен был инициировать встречу, потому что интересный проект. Если решил от проекта подальше - плохой знак. Лучше тогда обойти стороной и не переводить бухгалтерию. Либо позже перевести, если есть силы, в приказном порядке с поддержкой руководства и с позитивной и негативной мотивацией для отдела, особенно после выявления расхождений и некомпетентных действий со стороны бухгалтерии.
"аудит не принес внятных и понятных результатов" - звучит очень загадочно...
"Отрицательных позиций очень много, всплывают ошибки, вызванные изменением настроек программы туда-сюда. Подключаются программисты. Просто убираем минуса на конец месяца списанием-оприходованием" - Ошибки точно не таким способом желательно убирать. Или хотя бы временно. Консультант по ошибкам должен сказать, что и где не так. И закрытие месяца - самая приоритетная задача, и еще с первоначальных данных на тестовой базе нужно тренироваться закрывать, чтобы часть ошибок сразу отсеять. Но, как показывает опыт, анализ ошибок закрытия ведет к изменениям в методике ведения учета. "На рельсы" ведение учета именно для закрытия месяца нужно ставить и исходя из устраненных проблем выработать условия для ведения (структура предприятия, настройки складов, организаций), достигнуть оптимального баланса, чтобы и месяц без ошибок закрывался и настройки более-менее устраивали пользователей и руководство, которое отчеты хочет смотреть в определенных разрезах.
Приоритет неожиданно сместился с производства на бухгалтерию, но производство продолжали делать.
По вариантам, которые желательно было бы рассмотреть и придумать другие решения::
- оставить бухгалтерию как есть, настроить обмен с КА
- по номенклатуре и другой НСИ: нужно определить главную базу для создания/ведения НСИ, приоритет должен в любом случае быть по базам
- "Консультант воюет с настройками базы, возвращает в исходное состояние измененные главным бухгалтером настройки по фин. результату, настраивает бухгалтерский учет" - первоначальные настройки должны быть согласованы и зафиксированы, и желательно не допускать изменять даже главбуху, который, судя по рассказу, не совсем понимал что делал.
- результаты инвентаризации должны принести результат, если не принесли, значит что-то не сделали/ не смогли зафиксировать
- "возможность выбора организации в каждой строке авансового отчета" - вариант решения: создание рабочего места или мастер-документа для возможности создания нескольких авансовых отчетов по нескольким организациям в автоматическом режиме. Но никак не изменения типовых документов, которые участвуют в многих механизмах расчета.
По скрытым подводным камням, исходя из написанного:
Главбух очень странно себя повел, сам должен был инициировать встречу, потому что интересный проект. Если решил от проекта подальше - плохой знак. Лучше тогда обойти стороной и не переводить бухгалтерию. Либо позже перевести, если есть силы, в приказном порядке с поддержкой руководства и с позитивной и негативной мотивацией для отдела, особенно после выявления расхождений и некомпетентных действий со стороны бухгалтерии.
"аудит не принес внятных и понятных результатов" - звучит очень загадочно...
"Отрицательных позиций очень много, всплывают ошибки, вызванные изменением настроек программы туда-сюда. Подключаются программисты. Просто убираем минуса на конец месяца списанием-оприходованием" - Ошибки точно не таким способом желательно убирать. Или хотя бы временно. Консультант по ошибкам должен сказать, что и где не так. И закрытие месяца - самая приоритетная задача, и еще с первоначальных данных на тестовой базе нужно тренироваться закрывать, чтобы часть ошибок сразу отсеять. Но, как показывает опыт, анализ ошибок закрытия ведет к изменениям в методике ведения учета. "На рельсы" ведение учета именно для закрытия месяца нужно ставить и исходя из устраненных проблем выработать условия для ведения (структура предприятия, настройки складов, организаций), достигнуть оптимального баланса, чтобы и месяц без ошибок закрывался и настройки более-менее устраивали пользователей и руководство, которое отчеты хочет смотреть в определенных разрезах.
Приоритет неожиданно сместился с производства на бухгалтерию, но производство продолжали делать.
Вывод по сабжу простой - оценка рисков не проводилась никакая от слова "совсем". Ребята просто выскочили с шашками наголо, попытавшись работать теми же методами, что и на простых проектах - мол главное ввязаться в драку, а там за счет личного мастерства выехать.
Дробим работу на этапы. Один этап - это один месяц. Если не довольны или не платят, потеряем месяц - полтора работы, для нас не критично, это опыт, повесим на затраты. Отсутствие результата - это тоже результат, значит надо идти другим путем, но этот путь проверен и не подходит. На проектной работе отсутствие результата, тоже должно быть оплачено. Проект - он индивидуальный под заказчика, а не типовые конфигурации ставить и ИТС-ом банчить, где ценник и трудозатраты можно заранее просчитать, это всегда путь в неизведанное, по минному полю. За 12 лет работы, не было ни разу, двух одинаковых проектов, каждый требует полного погружения, самоотдачи и индивидуального подхода, бизнес модель "купи-продай" тут не работает, следовательно и оплачивается по индивидуальным договоренностям.
Описание проекта хорошее и разбор полетов грамотный.
От себя добавлю, на мой взгляд в проекте не разобрались с одной концептуальной вещью. Как меня 32 года назад научил один мудрый одесский еврей - "Если где-то на работе есть какой-то бардак, то он не просто так, всегда есть люди, кому этот бардак выгоден". Полагаю, что за каждым "бардаком" в учете заказчика стояли конкретные интересанты, они то и инициировали офисный саботаж.
И вторая мысль, как тут уже писал камрад starjevschik - бухгалтерия отдельно, управленческий учет - отдельно. А если не повезло, и приходиться иметь дело с КА, то тогда бухгалтерия - главный постановщик задач.
От себя добавлю, на мой взгляд в проекте не разобрались с одной концептуальной вещью. Как меня 32 года назад научил один мудрый одесский еврей - "Если где-то на работе есть какой-то бардак, то он не просто так, всегда есть люди, кому этот бардак выгоден". Полагаю, что за каждым "бардаком" в учете заказчика стояли конкретные интересанты, они то и инициировали офисный саботаж.
И вторая мысль, как тут уже писал камрад starjevschik - бухгалтерия отдельно, управленческий учет - отдельно. А если не повезло, и приходиться иметь дело с КА, то тогда бухгалтерия - главный постановщик задач.
Чтобы проект таких масштабов был в итоге успешным (со стороны заказчика) и, возможно, незакрытым со стороны организации-внедренца, необходимо с самого начала внедрения создать рабочую группу внутри штата - программисты, администраторы, консультанты, линия поддержки, ответственные за закрытие месяца, руководители группы (желательно 2 минимум), которые бы принимали участие в совещаниях, решали организационные вопросы и ставили задачи. Часть персонала можно взять из тех, что уже есть. Под специалистов и программистов сделать вакансии, должности и рыночные зарплаты.
Работая бок о бок со специалистами из франча, штатная рабочая группа - учится. Когда проект заканчивается по тем или иным причинам - его поддерживают и развивают уже собственные сотрудники. Большинство серьезных проблем, благодаря им, уйдет в ближайшие 2-3 года, когда руководство и пользователи свыкнуться с новой реальностью и начнут работать приказы, распоряжения, регламенты.
Внедрение современной учетной системы в наше время - неизбежная необходимость. Останавливать внедрение, даже при отсутствии средств это заранее согласиться с тем, что в будущем придется заплатить еще раз, возможно больше.
И кстати сейчас, блок производства, в таких системах как ERP пока еще сыроват для внедрения на крупных предприятиях. Ни платформа, ни конфигурация, ни интерфейс пока не могут удовлетворить всех потребностей в производственной сфере. Отсутствует как гибкость, так и производительность. Нам, к сожалению, с этим пришлось уже столкнуться. И решение пока не выработано. С той моделью производства, что реализовали разработчики ERP практически невозможно работать. В их представлении выпуск продукции - это локомотив без тормозов, который не имеет права останавливаться на остановках для погрузки/разгрузки, не может менять количество вагонов, маршруты следования, разделяться на 2 поезда, объединяться в один поезд и иметь длину состава больше протяженности перрона.
Работая бок о бок со специалистами из франча, штатная рабочая группа - учится. Когда проект заканчивается по тем или иным причинам - его поддерживают и развивают уже собственные сотрудники. Большинство серьезных проблем, благодаря им, уйдет в ближайшие 2-3 года, когда руководство и пользователи свыкнуться с новой реальностью и начнут работать приказы, распоряжения, регламенты.
Внедрение современной учетной системы в наше время - неизбежная необходимость. Останавливать внедрение, даже при отсутствии средств это заранее согласиться с тем, что в будущем придется заплатить еще раз, возможно больше.
И кстати сейчас, блок производства, в таких системах как ERP пока еще сыроват для внедрения на крупных предприятиях. Ни платформа, ни конфигурация, ни интерфейс пока не могут удовлетворить всех потребностей в производственной сфере. Отсутствует как гибкость, так и производительность. Нам, к сожалению, с этим пришлось уже столкнуться. И решение пока не выработано. С той моделью производства, что реализовали разработчики ERP практически невозможно работать. В их представлении выпуск продукции - это локомотив без тормозов, который не имеет права останавливаться на остановках для погрузки/разгрузки, не может менять количество вагонов, маршруты следования, разделяться на 2 поезда, объединяться в один поезд и иметь длину состава больше протяженности перрона.
(23) Какие красивые аллегории, уже несколько лет работаю в разных системах учета, в итоге самым эффективным способом оказалось изучить базовый функционал ка 1.1 и работать в нем дорабатывая мелкие доработки самостоятельно изучив код 1с.
какие-то сложные системы на базе erp внедрили местные сети, теперь работают в трех базах :) вбивая первичку в бухгалтерию упп и erp
такие дела
какие-то сложные системы на базе erp внедрили местные сети, теперь работают в трех базах :) вбивая первичку в бухгалтерию упп и erp
такие дела
Это Еще ничего. На своей заре я еще не такие перлы исполнял. Не хотел у меня как-то один клиент переходить на 1С, с какой досовской программы. Завод был средний. Человек 500. 1С купили, но все что-то у бухов времени нет начать. Дело было в период выхода Вин 2010 и затухания Вин 2008. Когда базу 1С 77 невозможно было на Вин 2008 открыть на 5 машинах по сети, из за ограничения по количеству файлов.
Вот я грамотный такой, наткнулся на это ограничение - это было уже всем известно, и объяснил руководству, что нужно менять винду на сервере, на 2010-ю. А мне и предложили переустановить, а я геройски и согласился, т.к. клиент был крупный. Программу купил, все оплатил, короче нужно было держаться. И свое начальство на франче подгоняет.
Взял я одним махом и и и диски форматнул, и винду переустановил. Поставил 1С, все заработало и я довольный отдыхаю. Приходят значит в понед. бухи, а свою старую программу запустить не могут. А потому что нет ее.
А она оказывается была на том же жестком диске, но в отдельном логическом разделе, который был с своей файловой системой, которая из винды нигде не была видна. А я то еще смотрел в утилите форматирования и не мог понять, что это там за 4 гига какой то раздел непонятный?
Поскольку на тот момент их программе уже было около 10 лет, то установить ее заново уже было некому.
Бекапы где то есть, но никто не знал уже где. Потом вроде бы как нашли, но никто уже не помнить как восстановить.
Не помню сколько я тогда времени бесплатно отработал чтобы помочь перейти в 1С, но таки перешли.
Что самое интересное у меня после них, еще пара таких случаев была. Один когда появились клиенты на 1С 77 SQL, еще один уже на 8-ке.
И вообще я с детства все разбирал, хотя родители говорят что ломал - но я с этим не согласен...
Вот я грамотный такой, наткнулся на это ограничение - это было уже всем известно, и объяснил руководству, что нужно менять винду на сервере, на 2010-ю. А мне и предложили переустановить, а я геройски и согласился, т.к. клиент был крупный. Программу купил, все оплатил, короче нужно было держаться. И свое начальство на франче подгоняет.
Взял я одним махом и и и диски форматнул, и винду переустановил. Поставил 1С, все заработало и я довольный отдыхаю. Приходят значит в понед. бухи, а свою старую программу запустить не могут. А потому что нет ее.
А она оказывается была на том же жестком диске, но в отдельном логическом разделе, который был с своей файловой системой, которая из винды нигде не была видна. А я то еще смотрел в утилите форматирования и не мог понять, что это там за 4 гига какой то раздел непонятный?
Поскольку на тот момент их программе уже было около 10 лет, то установить ее заново уже было некому.
Бекапы где то есть, но никто не знал уже где. Потом вроде бы как нашли, но никто уже не помнить как восстановить.
Не помню сколько я тогда времени бесплатно отработал чтобы помочь перейти в 1С, но таки перешли.
Что самое интересное у меня после них, еще пара таких случаев была. Один когда появились клиенты на 1С 77 SQL, еще один уже на 8-ке.
И вообще я с детства все разбирал, хотя родители говорят что ломал - но я с этим не согласен...
(24) Интересно у вас получилось. Вообще бэкап - наше все, перед любыми задачами, тем более если не понимаешь для чего это нужно. А вообще лучше на личных данных (не на работе) учиться. Сам когда-то давно потерял фотоархив личный, после чего усвоил правило 3-2-1.
Ну что сказать. Самая главная ваша ошибка - это ваша ничем не обоснованная самоуверенность. Вы сейчас расписали "чудесную" историю из которой видно следующее. В начале вы описываете компанию, как быстро растущую, но при этом как этаких "дурачков", которые все ведут в экселе и УТ, а потом по факту окажется, что кроме экселя использовалась Бух, УПП. И вы решаете, что вы этакие "спасители", которые научат как надо все делать. Проще надо быть и не считать всех вокруг дурачками, потому что дурачками в итоге остались вы сами. Было куча и других ошибок, но они все производные от вашей самоуверенности. Причина в вас самих, как внедренцах, клиенты тут вообще не причем.
(25)Ну там как бы проходи красной нитью что саботировал проект Бух, внедренцы же к нему подходили, а он/она их футболила. Отсюда вывод: Она не заинтересована, т.к. имеет фин.интерес иметь руководителя. Руководитель, скорее всего, это осознал, но гл. бух, являясь носителем СТРОГО конфиденциальной информации, может нанести ощутимый вред, если его - "тавой". Опасная для предприятия ситуация. Я бы посоветовал, не терять контакт с руководителем, и периодически интересоваться, все ли у них хорошо, т.к. бух может уже и не глав. и можно по новой "заскочить" на проект.
(29) Нет, все не так про саботажников. Это вам так пытаются подать историю, что все вокруг саботажники, а внедренцы "белые и пушистые". Таких историй я много насмотрелся. И в таких историях нужно слушать две стороны, тогда можно сложить картину в целом. А так, мой вывод: самоуверенность внедренцов, которые считали себя самыми умными их подвела.
В комментариях много критики, якобы сам виноват. На деле почти всегда получается так, что руководство с обеих сторон не может адекватно оценить ни стоимость, ни сроки, ни сложность работы. Задайте себе вопрос, часто ли с вами руководство обсуждает сроки и план работ до того как начать что-то внедрять?
Я видел, как программисты 1С на проекте "разбивались в труху", ночуя в офисе, пытаясь успеть сдать что-то к срокам, думая, что это спринт. А это был затяжной марафон, где никакие сверхурочные, работы по выходным и праздникам уже не вернут опоздание на несколько месяцев. Только вымотают всю команду так, что они будут от силы писать пару строк кода в день, т.к. мозг уже не работает или вообще пожелают уйти в другое место, т.к. работа не должна занимать 90% жизни.
Я видел, как программисты 1С на проекте "разбивались в труху", ночуя в офисе, пытаясь успеть сдать что-то к срокам, думая, что это спринт. А это был затяжной марафон, где никакие сверхурочные, работы по выходным и праздникам уже не вернут опоздание на несколько месяцев. Только вымотают всю команду так, что они будут от силы писать пару строк кода в день, т.к. мозг уже не работает или вообще пожелают уйти в другое место, т.к. работа не должна занимать 90% жизни.
(27) Да, количество стараний и проложенных усилий, объем работ сами по себе не влияют на результат. Нужно видение и понимание происходящего, постоянный анализ и принятие решений что делать дальше. У руководства не всегда есть адекватное видение, бывает нет понимания, или иллюзия только всего этого. А страдают потом все.
Сейчас работаю над переходом с "в калл" переписаной УПП естественно под бизнес процессы компании (переписывали 11 лет, где .НайтиПоКоду() и считается в порядке вещей), свой блок бюджетирования, различные регламентные задания по перепроведению бюджетных документов для актуализации данных в самописных же отчетах, кучей юрлиц на максимально возможно типовую КА2. Интересно, в общем)
Почему проект нельзя было по шагам делать ?
Бух для начала в порядок привести - и как удобно бухам и глав. буху.
Торговлю отдельно, как удобно манагерам + обмены.
Ну и только потом УПП или аналогичное
Тем более раз клиент проблемный
Бух для начала в порядок привести - и как удобно бухам и глав. буху.
Торговлю отдельно, как удобно манагерам + обмены.
Ну и только потом УПП или аналогичное
Тем более раз клиент проблемный
(35)
Потому что заказчик только на словах хочет оплачивать по шагам, а на деле после первого шага он не получит "весь результат" которого он ожидает и будет переводить отношения в русло "вот всё сделаете, всё сразу и оплачу", "покажите результаты, тогда оплачу", "покажите что вы сделали, тогда оплачу" и тд.
Вот представьте вы заказали проект кухни, вам сделали проект на ПК и сказали что напилили доски и ждут когда привезут фурнитуру, вы ещё ничего не получили, но с вас уже просят деньги, они же поработали, вы же хотите оплатить понятный для вас результат, а не какие то "напиленные" доски которых вы даже не видели. И вы конечно скажите то что вы там пилили и заказывали это хорошо, но это не результат, будет результат, будут деньги.
Если клиент "проблемный" то это не клиент... Просто "маленьким" франчам как то надо выживать, вот они и берутся поработать за еду и опыт. Вот тут поработали за опыт.
Почему проект нельзя было по шагам делать ?
Потому что заказчик только на словах хочет оплачивать по шагам, а на деле после первого шага он не получит "весь результат" которого он ожидает и будет переводить отношения в русло "вот всё сделаете, всё сразу и оплачу", "покажите результаты, тогда оплачу", "покажите что вы сделали, тогда оплачу" и тд.
Вот представьте вы заказали проект кухни, вам сделали проект на ПК и сказали что напилили доски и ждут когда привезут фурнитуру, вы ещё ничего не получили, но с вас уже просят деньги, они же поработали, вы же хотите оплатить понятный для вас результат, а не какие то "напиленные" доски которых вы даже не видели. И вы конечно скажите то что вы там пилили и заказывали это хорошо, но это не результат, будет результат, будут деньги.
Тем более раз клиент проблемный
Если клиент "проблемный" то это не клиент... Просто "маленьким" франчам как то надо выживать, вот они и берутся поработать за еду и опыт. Вот тут поработали за опыт.
(36) Напилили доски. Заказчик говорит, что это не результат. Оплачивать не хочет. Все. Конец. Но Вы потеряли только 10 часов, а не 800. Все-таки можно с таких заказчиков зарабатывать, но это тяжело, нудно и действительно больше для опыта, а не для денег.
Тут проблема вообще в другом была:
Организационная со стороны заказчика:
1)Руководителю было все равно
2)Корректного ведения учета не было нигде (Excel, бумаги,..., сторонняя программа)
3)Решения плохо спускались по вертикали власти.
4)Руководитель не платил за работу, а значит не отвечал своим карманом и не мотивировал тем самым своих сотрудников.
Организационная со стороны исполнителя:
1)Весь проект не был разбит на этапы. Можно использовать разные методики, например,
Agile, Scrum, Kanban, PRINCE2 и другие, но у каждого периода должна быть отсечка с результатом
2)После каждого завершенного этапа заказчик должен платить, если не платит. Сразу прекращать с ним сотрудничество.
Соответственно, если периодом подведения промежуточных итогов будет месяц, то это и есть ваши риски.
Потеряли бы 160 часов всего максимум.
Организационная со стороны заказчика:
1)Руководителю было все равно
2)Корректного ведения учета не было нигде (Excel, бумаги,..., сторонняя программа)
3)Решения плохо спускались по вертикали власти.
4)Руководитель не платил за работу, а значит не отвечал своим карманом и не мотивировал тем самым своих сотрудников.
Организационная со стороны исполнителя:
1)Весь проект не был разбит на этапы. Можно использовать разные методики, например,
Agile, Scrum, Kanban, PRINCE2 и другие, но у каждого периода должна быть отсечка с результатом
2)После каждого завершенного этапа заказчик должен платить, если не платит. Сразу прекращать с ним сотрудничество.
Соответственно, если периодом подведения промежуточных итогов будет месяц, то это и есть ваши риски.
Потеряли бы 160 часов всего максимум.
(38)
Заказчики не очень горят желанием оплачивать предпроектное обследование как отдельный этап. По этому франчи с начало обещают, а потом думают как они это будут делать. На подписании договора и обсуждении работ все друг другу улыбаются и хотят платить по этапам, пока не настало время закрыть первый этап и получить деньги.
"Доступно и всерьёз"
Организация со стороны исполнителя пообещала то, что не могла выполнить, так как сначала пообещала, а потом пошла выяснять, что и как надо выполнить.
Заказчики не очень горят желанием оплачивать предпроектное обследование как отдельный этап. По этому франчи с начало обещают, а потом думают как они это будут делать. На подписании договора и обсуждении работ все друг другу улыбаются и хотят платить по этапам, пока не настало время закрыть первый этап и получить деньги.
"Доступно и всерьёз"
Еще важно чтобы заказчик знал о теоретической сумме по верхней границе проекта. Потому что будет обидно когда оценили по средней, по дороге всплыло 1000000 неучтенных правок, а у клиента денег не хватает даже чтобы оплатить по минимальному прайсу. Итог: куча невероятных затрат компании, очень мало опыта, настроение команды на уровне цокольного этажа..
А по этой истории очень важно поэтапное внедрение. Например сначала автоматизировать деньги, взаиморасчеты, показать результат, получить оплату. Потом над, например, прродажами, время оформления заказа привести к минимуму, учитывая особенности отдела продаж. Потом закупки, закусить производством и зп. И когда все уже работает - закрывать период и финрез. И после каждого этапа брать денежку. Понятно что висящие в воздухе заказы, или РКО без начисления ЗП - это плохой пример для заказчика, но..
А по этой истории очень важно поэтапное внедрение. Например сначала автоматизировать деньги, взаиморасчеты, показать результат, получить оплату. Потом над, например, прродажами, время оформления заказа привести к минимуму, учитывая особенности отдела продаж. Потом закупки, закусить производством и зп. И когда все уже работает - закрывать период и финрез. И после каждого этапа брать денежку. Понятно что висящие в воздухе заказы, или РКО без начисления ЗП - это плохой пример для заказчика, но..
(43) Параллельно пользователи работают в старой учетной системе. Но новые уже видят то что им надо. Допустим кассир не видит как рассчитывают зп, и не видит НДС. Она видит оплату, поступление денег, она знает назначение и сумму в кассе. Дальше продавец. Он не видит что товар прищел из производства или от поставщика или просто нашли в закромах у уже сидящего бывшего кладовщика. Он видит что клиенту можно продать и он продает. итд. В итоге каждый видит свой кусок кроме пользователей которые сидят на стыке двух кусков. Далее в ночь на выходные новоразработанная база очищается, старая закрывается, записываются начальные остатки, и в понедельник утром начинается вой "у меня там в 7.7 была ошибка, нужно исправить, я ее лелеяла 4 месяца, а из за нее у меня ничего не сходится!!" поэтому выключаем телефон, и пусть они штурмуют с крайне ******кими вопросами своих начальников. На третий день выходим из отпусков и решаем уже реальные проблемы.
Вы скажите "да вы что, никто не согласится на такой вариант", а я вам скажу что хватит терпеть такой вариант. Если никто не согласится слушать вой и.о. зам.помощника 4-го справа кладовщика о том что "вообще то партионный учет я знаю лучше" - то они все вымрут и выть будет некому.
Шутка конечно, но с долей правды. Клиенты работали в том самом экселе, и ввод начальных остатков не такой и сложный был..
Вы скажите "да вы что, никто не согласится на такой вариант", а я вам скажу что хватит терпеть такой вариант. Если никто не согласится слушать вой и.о. зам.помощника 4-го справа кладовщика о том что "вообще то партионный учет я знаю лучше" - то они все вымрут и выть будет некому.
Шутка конечно, но с долей правды. Клиенты работали в том самом экселе, и ввод начальных остатков не такой и сложный был..
Сейчас предстоит такой же винегрет первоначально сделали переход своими силами из 77 начальство сказало нет, приглашаем сторонних те взяли деньги и проект перенесли на новый год, пока ни строчки от них нет с мая и в тесте работает на наших данных и доработках, вот взгляд с другой стороны когда приходят не разбираясь в бизнес процессах определенной компании говорят все сделаем, а в итоге говорят извините нужно перестраивать учет
(44)
Перестраивать учёт во время внедрения нового софта это нормальная практика. Всегда есть то что можно улучшить.
В этом вся и проблема. Зачастую не только процессы какой то конкретной компании не знают, не имеют вообще опыта в отрасли. Как ТС писал им нужен был опыт по КА 2.2, они его получили. Что просишь, то и получаешь, надо просить деньги :)
а в итоге говорят извините нужно перестраивать учет
Перестраивать учёт во время внедрения нового софта это нормальная практика. Всегда есть то что можно улучшить.
вот взгляд с другой стороны когда приходят не разбираясь в бизнес процессах определенной компании говорят все сделаем
В этом вся и проблема. Зачастую не только процессы какой то конкретной компании не знают, не имеют вообще опыта в отрасли. Как ТС писал им нужен был опыт по КА 2.2, они его получили. Что просишь, то и получаешь, надо просить деньги :)
Я соглашусь с тем, что нельзя все время плясать под дудку заказчика.
Аргументы очень простые:
если заказчик перестроит свои процессы, как ему велит исполнитель, ему внедрение обойдется условно 1млн. руб.
Если он скажет, оставьте, как есть, то ему обойдется в 10 млн. руб.
Аргументы очень простые:
если заказчик перестроит свои процессы, как ему велит исполнитель, ему внедрение обойдется условно 1млн. руб.
Если он скажет, оставьте, как есть, то ему обойдется в 10 млн. руб.
Бывают нормальные заказчики, бывают нет. Если заказчик плохой, то работать надо с помощью каких-то бумажек типа ТЗ. Если проект большой, то его надо разбивать на мелкие этапы. Писать маленькие ТЗ на каждый этап, где четко прописано что делается и за что платятся деньги. Оплата по этапам. Как только этап не оплатили - все, конец работе.
(61) Это вопрос терминологии, но если не спорить о ней, то по сути согласен. У меня был случай, когда я почувствовал, что заказчик "плохой" в моей терминологии. Одну задачу он оплатил, потому что она была простая и дешевая. Но я уже все о нем понял. На вторую задачу я составил детальное ТЗ и дал оценку по времени и деньгам. Он посмотрел на цену и отказался, хотя я предлагал еще и дешево. Т.е. если мы чувствуем, что заказчик неплатежеспособен, то мы обязаны на начальном этапе давать ему четко понять сколько это будет стоить, сколько займет времени, причем результаты, которые мы с заказчиком хотим совместно достичь должны быть четко формализованы на бумаге и подписаны заказчиком. Причем грубой ошибкой будет оценивать весь проект. Проект должен быть разбит на маленькие этапы с четкой формализацией. Это нужно чтобы заказчик в первую очередь понимал сколько это будет ему стоить. Цена - это важнейший вопрос. Есть шанс, что заказчик, увидев цену, сам откажется и никто из сторон не будет страдать зря.
А плохой, неплатежеспособный, - можно придумывать разные термины. Он может быть неплатежеспособный для одних задач, и вполне платежеспособным для других. Главное правильно оценивать задачу. Это вопрос профессионализма разработчика - верная оценка. Чтобы не оказаться в дураках, риски нужно вешать на заказчика, если мы видим, что он плохой.
А плохой, неплатежеспособный, - можно придумывать разные термины. Он может быть неплатежеспособный для одних задач, и вполне платежеспособным для других. Главное правильно оценивать задачу. Это вопрос профессионализма разработчика - верная оценка. Чтобы не оказаться в дураках, риски нужно вешать на заказчика, если мы видим, что он плохой.
(65) В 90% заказчику все эти ТЗ фиолетовы, для него важен сам проект и конечные точки этого проекта, а не куча ТЗ на доработки которые решают локальные проблемы, но не решают общей задачи. Нужно внедрять тот функционал который есть в системе, даже если этот функционал гавно, и если заказчику это не нравиться вот тогда и составлять ТЗ на доработку, тогда гарантия оплаты таких задач будет намного выше.
Я в основном работаю на аутсорсинге, и очень часто выступаю и как заказчик и как исполнитель, и поверьте обосновать доработки системы очень сложно, всегда ищу другие решения, хотя эти решения очень сложные и часто приводят к серьезным конфликтам, но руководство все равно идет не на доработку системы а на решение этих проблем, разными путям, вплоть до увольнения сотрудников и подбора новых
Я в основном работаю на аутсорсинге, и очень часто выступаю и как заказчик и как исполнитель, и поверьте обосновать доработки системы очень сложно, всегда ищу другие решения, хотя эти решения очень сложные и часто приводят к серьезным конфликтам, но руководство все равно идет не на доработку системы а на решение этих проблем, разными путям, вплоть до увольнения сотрудников и подбора новых
(90)Заказчик знает чего он хочет от системы автоматизации, а 1С это или не 1С ему не интересно, если 1С не дает нужный функционал заказчик решает будет он вкладывать в дописку этого функционала или нет, и притом он хочет это знать до запуска проекта а не в середине.
(94)После внедрения систем как правило их переписывают до не узнаваемости, а вот когда идет внедрение практически не трогают типовой функционал. Я сталкивался с ситуацией когда после внедрения КА, ее в последствии переписали можно сказать в УПП, результат, вложили средств в несколько раз больше чем если бы внедрили УПП.
Если заказчик плохой, то работать надо с помощью каких-то бумажек типа ТЗ.
Если заказчик "плохой" то работать с ним не стоит.
Сколько раз видел попытки работать с "плохим" заказчиком по средствам ТЗ, этапов, проектных подходов и тд... все закончились одинаково.
"горбатого могила исправит", а не ТЗ и поэтапная оплата.
Вы не зря это прошли.
Мне очень пригодится.
Все хотят учится на чужих ошибках,
а про свои не разглашают...
очень содержательно и доходчиво рассказали.
спасибо за пережитую историю ,
понимаю , что не очень приятную ,
пусть вас Бог благословит .
Мне очень пригодится.
Все хотят учится на чужих ошибках,
а про свои не разглашают...
очень содержательно и доходчиво рассказали.
спасибо за пережитую историю ,
понимаю , что не очень приятную ,
пусть вас Бог благословит .
Кстати, все, что произошло, можно было упростить. Надо было сразу примерно оценить задачу. Понятно, что точно ее оценить было бы невозможно, но опыт показывает, что даже интуитивно можно это сделать с ошибкой в 2 раза. Например, оценили в 1000 часов. Умножаем на 2. Получается 2000 часов. Т.е. примерно 3 000 000 р. по провинциальным, допустим, меркам. Дальше говорим заказчику цену. Уже на этом этапе он скорее всего откажется. А если вдруг не откажется, то бьем задачу на этапы с поэтапной оценкой и оплатой, о чем здесь многие писали. И это уже будет другая - более точная оценка. Единственный вопрос - кто заплатит за предпроектное обследование. Т.е. по большому счету в этой проблеме всего один главный вопрос - может ли себе разработчик позволить бесплатное предпроектное обследование? Но если вдруг заказчик может оплатить предпроектное обследование - в принципе это уже значит, что вопрос решен в выгодную для разработчика сторону.
Нельзя верить на слово сотрудникам заказчика. Опрашиваемый может не знать, не помнить, иметь ошибочное представление. На пректах с таким количеством часов необходимо обследование. И работа по предоплате, а закрытие результатов поэтапное. Это снижает Ваши риски и стимулирует Заказчика получить результат, а не кинуть на деньги когда всё готово. Да и платить по частями легче, чем всю сумму в конце.
Интересность Заказчика зависит от Вашей текущей загруженности другими проектами. За время проекта все может поменятся. Плюс есть риски со стороны Заказчика на которые Вы не можете влиять. Этапы позволят быстро переключаться между проектами и сократит риски бесплатной работы.
Интересность Заказчика зависит от Вашей текущей загруженности другими проектами. За время проекта все может поменятся. Плюс есть риски со стороны Заказчика на которые Вы не можете влиять. Этапы позволят быстро переключаться между проектами и сократит риски бесплатной работы.
(73) Все врут (с). Согласен.
Давеча, мне на голубом глазу кричали, что вот тут в базе, должны быть документы, мы их "вчера" печатали... правда документы оказались с мокрыми печатями банка =))) Да и шрифт, размер и формат не соответствовал...
Директор - "Так что же МарьИвановна врет что ли?"
Я - "Наверное, она просто ошиблась, закрутилась, много работы, вот и ошиблась"...
Но не стоит лезть в бутылку, даже если вы правы на 100%
Давеча, мне на голубом глазу кричали, что вот тут в базе, должны быть документы, мы их "вчера" печатали... правда документы оказались с мокрыми печатями банка =))) Да и шрифт, размер и формат не соответствовал...
Директор - "Так что же МарьИвановна врет что ли?"
Я - "Наверное, она просто ошиблась, закрутилась, много работы, вот и ошиблась"...
Но не стоит лезть в бутылку, даже если вы правы на 100%
Был у меня один опыт автоматизации на производственном предприятии. Работали вдвоём, основную часть работ.
Конечно же, в первую очередь, мы работали с бухгалтерией, потому что в конечном итоге все информационные потоки сходятся именно туда, в любых случаях. Нам это помогло в том плане, что основные бизнес-процессы мы в бухии запустили и потом только стали заходить в оперативный контур. Вот там и вылезли нюансы в виде кучи разных самописных программок в производстве, которые даже не были полностью друг с другом сопряжены, как оказалось. Мы смогли победить и это, как вдруг... Оказалось, что на наш проект заходит другой исполнитель, а наше участие было ограничено сроком заключенного между нами договора. Как показало время, руководство этого предприятия не ожидало, что мы сможем решить ряд задач, которые они считали для себя невыполнимыми. Как здесь уже в чате сказано, там многим был выгоден такой бардак, поскольку позволял им кое-что делать в мутной воде...
Первое время они тоже платили без проблем, в том числе и за предпроектное обследование. А когда поняли, что мы предприятие на новые рельсы уже практически поставили, и подчиненные уже стали более лояльно относиться к новой системе, нежели к старой - вот тут они и показали свои истинные намерения. Конечно же, мы немного попытались побороться, но весовая категория у нас была не та. Мы оттуда вынуждены были уйти, хотя до сих пор многие наши внедренные решения работают (спустя 2 года). В подтверждение своей версии (бардак в чьих-то интересах) могу сказать, что нашим последователем по 1С так ничего нового и не было внедрено.
Но, конечно же, мы работали только по этапам и срокам. Сроки подошли, мы отчитались по этапам, подписали акты и в течение трех рабочих дней получили деньги. Поэтому - да, клиент сложный, да, было много проблем и все такое. Но, деньги при этом мы свои получали, то есть потери у нас были, но минимальные.
А сейчас это предприятие уже перепродано другим собственникам, бывшие руководители под следствием.
Конечно же, в первую очередь, мы работали с бухгалтерией, потому что в конечном итоге все информационные потоки сходятся именно туда, в любых случаях. Нам это помогло в том плане, что основные бизнес-процессы мы в бухии запустили и потом только стали заходить в оперативный контур. Вот там и вылезли нюансы в виде кучи разных самописных программок в производстве, которые даже не были полностью друг с другом сопряжены, как оказалось. Мы смогли победить и это, как вдруг... Оказалось, что на наш проект заходит другой исполнитель, а наше участие было ограничено сроком заключенного между нами договора. Как показало время, руководство этого предприятия не ожидало, что мы сможем решить ряд задач, которые они считали для себя невыполнимыми. Как здесь уже в чате сказано, там многим был выгоден такой бардак, поскольку позволял им кое-что делать в мутной воде...
Первое время они тоже платили без проблем, в том числе и за предпроектное обследование. А когда поняли, что мы предприятие на новые рельсы уже практически поставили, и подчиненные уже стали более лояльно относиться к новой системе, нежели к старой - вот тут они и показали свои истинные намерения. Конечно же, мы немного попытались побороться, но весовая категория у нас была не та. Мы оттуда вынуждены были уйти, хотя до сих пор многие наши внедренные решения работают (спустя 2 года). В подтверждение своей версии (бардак в чьих-то интересах) могу сказать, что нашим последователем по 1С так ничего нового и не было внедрено.
Но, конечно же, мы работали только по этапам и срокам. Сроки подошли, мы отчитались по этапам, подписали акты и в течение трех рабочих дней получили деньги. Поэтому - да, клиент сложный, да, было много проблем и все такое. Но, деньги при этом мы свои получали, то есть потери у нас были, но минимальные.
А сейчас это предприятие уже перепродано другим собственникам, бывшие руководители под следствием.
Все коментарии не успел прочесть.
Автор попытался сделать БОЛЬШОЙ проект, там где УЧЕТ (хотя бы! я не говорю уже о фактической регистрации чего бы то ни было) отсутствовал как класс (ведение "учета" - как в этом проекте - в режиме "записной книжки" - это не учет).
Соответственно прежде чем что-либо делать - надо было начинать с НАВЕДЕНИЯ ПОРЯДКА (как отдельный проект), что само по себе достаточно тяжелая задача, а потом, собственно, уже делать сам проект. Если все делать в рамках одного проекта - то это совсем другой масштаб у этого проекта должен был быть, построена работа по другому, ну и полномочия у внедренцев - тоже совсем другие. То есть, в итоге, неправильно оценен изначально проект.
.
но! Грабли, которые мы обходим, лишают нас бесценного опыта ;-)
а так, конечно, познавательно и полезно написано.
.
автор молодец хотя бы тем, что написал честно. а то как кого не почитаешь\спросишь - одни победные реляции...
Автор попытался сделать БОЛЬШОЙ проект, там где УЧЕТ (хотя бы! я не говорю уже о фактической регистрации чего бы то ни было) отсутствовал как класс (ведение "учета" - как в этом проекте - в режиме "записной книжки" - это не учет).
Соответственно прежде чем что-либо делать - надо было начинать с НАВЕДЕНИЯ ПОРЯДКА (как отдельный проект), что само по себе достаточно тяжелая задача, а потом, собственно, уже делать сам проект. Если все делать в рамках одного проекта - то это совсем другой масштаб у этого проекта должен был быть, построена работа по другому, ну и полномочия у внедренцев - тоже совсем другие. То есть, в итоге, неправильно оценен изначально проект.
.
но! Грабли, которые мы обходим, лишают нас бесценного опыта ;-)
а так, конечно, познавательно и полезно написано.
.
автор молодец хотя бы тем, что написал честно. а то как кого не почитаешь\спросишь - одни победные реляции...
"Ну а теперь выводы и ошибки. "
А было ли предпроектное обследование? Оно было оформлено как документ и подписано Заказчиком?
Я так понимаю, что документы План проекта, Рамки проекта и оценка рисков не были разработаны вообще?
Мне кажется основная ошибка в том, что Проект, действительно большой, выполнялся совсем не проектным образом.
Заказчик всегда прав, если он не подписал обратное.
А было ли предпроектное обследование? Оно было оформлено как документ и подписано Заказчиком?
Я так понимаю, что документы План проекта, Рамки проекта и оценка рисков не были разработаны вообще?
Мне кажется основная ошибка в том, что Проект, действительно большой, выполнялся совсем не проектным образом.
Заказчик всегда прав, если он не подписал обратное.
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|