От lessonslearned:
 

Прошу прощения, долго не отвечал. Был занят...
Приступим...

0. Стадия Диагностики (пресейл со стороны подрядчика) обсуждение целей и границ проекта, общее видение, кто именно из сотрудников заказчика и чем будет заниматься в проекте, подписание договора.
1. Стадия Анализа. Сбор функциональных требований к сайту. Сбор требований ко внешнему оформлению. 4 недели. Участники – все заинтересованные стороны со стороны заказчика. Упор на экспертах (знания) и менеджерах (полномочия). Со стороны подрядчика – аналитик.
2. Стадия Проектирования. Написание ТЗ. Написание технических спецификаций интерфейсов и интеграции. Технический проект при необходимости. 6 недель. Из них от 2 до 4 часов в неделю уделяется пересмотру функциональных требований и выявлению новых требований. Участники – команда управления проектом, ключевые пользователи. Также, создаются планы на миграцию, наполнение контентом. На данной стадии завершен бриф для дизайнера.
3. Стадия Разработки. Разработка системы. Модульное тестирование системы (возможно с заказчиком). Внесение небольших изменений как в технические задания, так и в функциональные. Жесткая привязка к срокам и бюджетам. Все изменения, какие только возможно выносятся в релиз 2, за рамки текущего проекта. Интеграционное тестирование. Нагрузочное тестирование. Внешнее оформление. 8 недель. Участники – разработчики, ключевые пользователи.
4. Стадия развертывания. Перенос системы на хостинг. Приемочное тестирование пользователями. Окончательное наполнение контентом и написание инструкций. Обучение ключевых пользователей и администраторов. 2 недели. Участники – ключевые пользователи, команда управления проектом.
5. Этап Завершения. Формируется архив проекта. Бесплатный период поддержки и исправления ошибок. Заключение договора на поддержку и на выполнение 2-го релиза. 2 недели

Итого: 22 недели или почти 5 месяцев. За это время созданы боевая среда, среда разработки, документация с точки зрения бизнеса (функциональные требования), техническая документация, документация для конечных пользователей, проведено обучение пользователей, ясны дальнейшие планы развития сайта. Более, того, система не привязана к хотелкам пользователей, т.к. все изменения проходили рассмотрение и оценку “людьми, которые платят”, а также, снижена зависимость от персоналий (есть все необходимые описания и инструкции, что позволяет увеличить скорость подготовки персонала в случае увольнения). Сформировано ядро специалистов по системе у заказчика. Как минимум, было не просто “тырканье по кнопкам”, а осмысленные действия за счет приемочного тестирования. Ну и последнее, у заказчика появилась и экспертиза и первоначальная база знаний (архив проекта) для ведения будущих проектов.

Где-то так... Что скажете?

От s_ustinov:
 

lessonslearned

Где-то так... Что скажете?

Не верю :-)))

заказчику надо быстро получить работающий сайт - а ему говорят - через 20 недель увидишь готовую систему... за миллион денег... (я ведь правильно понял, что объемы работ "как раз" вписались в бюджет?))))
впрочем, это уже лирика.. в конце концов, клиент всегда прав в том, как именно он желает потратить свои деньги... )))

насколько я могу судить - так тоже можно внедрить.
единственное но - не уверен, что такие цены конкурентоспособны.
штат фирмы - 20 человек. скорее всего в день сайт будет посещать не более тысячи посетителей (и это еще очень завышенная оценка)
можно конечно много времени убить на рисование анимации... вот только сайт деловой - зачем она там?

то есть для такого рода фирм это не очень реалистичный проект - при нормальном конкурсе такое предложение не выиграет тендер.

От s_ustinov:
 

а давайте обсудим второй пример - с фермерами.
он мне кажется как раз намного более "жестким" по срокам и бюджету.
вот только одно уточнение - планирование ДДС - каким оно должно быть?
я частично пересекался с "фермерами" - там действительно спланировать деньги без разрывов большая проблема. и цены на то же ГСМ (а это одна из наиболее существенных статей затрат) меняются достаточно быстро.
то есть вопрос вот в чем - как мне кажется, заказчику может хотеться получить следующее - я указываю, сколько солярки, удобрений, семян и т.п. и когда мне надо (и желательно с возможностью задавать диапазон по объемам и срокам), сколько и когда я смогу продать пшеницы, гречки, кукурузы и прочего сена, какие на это все цены, какие сроки платежей, какие еще мне работы надо заказать (например нанять самолетик опрыскать вредителей отравой), сколько у меня и каких относительно постоянных расходов (зарплата, аренда и т.п.) - и система мне рисует график с указанием всех разрывов. и чтобы в любой момент можно было указать другую цену или объем или добавить новый вид расходов - и все автоматом пересчиталось. также хорошо бы иметь возможность сравнивать план ДДС с фактом - за счет чего у нас не идет и на сколько - и заодно постоянно уточнять модель.
То есть основная проблема с деньгами у фермеров - возникновение доходов и расходов сильно разнесено во времени и суммы зависят от очень большого числа факторов - очень нестабильны - постоянно меняются необходимые объемы удобрений, цены на продукцию и ГСМ, планируемый объем и сроки урожая и т.п.
и планировать, указывая СУММЫ не получится - цена на горючее меняется на 20% (а это очень частое явление) - и все надо пересчитывать, что вручную крайне трудоемко и никто этого делать не будет.
ВСЕ ЭТО планируется внедрить за 350 тысяч (включая лицензии) и за 2,5 месяца? или это есть во внедряемом продукте? фраза - "позволяющая автоматизировать учет и отчетность" наводит на мысль, что ничего подобного для целей планирования там и близко нет :-)))
или же я неправ, и под планированием ДДС в этом проекте подразумевается нечто другое?

От Андрей_Ж:
 

Когда – то выиграл тендер на замену учётной системы на малом предприятии оптовой торговли. В качестве условия нужно было предоставить календарный и финансовый план, а так же определить сроки внедрения в письменном виде. Конечно вид у документа «колхозный», но его еще несколько раз применял, как «методику внедрения». Может будет полезно! (Ж – разработчик/внедренец, З - операторы, Н – главбух, В – хозяин). Не ругайтесь, если "не в тему".

План внедрения системы «КИС Lack» в фирме оптовой торговли «ХЗ».

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

Календарный план внедрения:

Август.
Обучение оператора (З) вводу прихода и формированию отгрузочных накладных. Ознакомления с основными атрибутами товаров, клиентов, накладных. Ввод остатков товаров на любую дату.
В, Н. Ознакомление с основными отчетами по движению товаров.
Ж. Настройка программы на реквизиты фирмы.

При успешном вводе остатков возможен переход на новую систему, при условии параллельного ведения двух программ. Принятие решения о смене ПО.

Сентябрь.
Обучение З, Н всем оперативным режимам программы (накладные, счета фактуры, списание, инвентаризация) с разделением документов на «черные и белые», обучение основным оперативным отчетам. Освоение методов ускорения работы. Ведение и анализ сроков годности товаров.
В, Н. Ведение финансовых операций (несколько расчетных счетов). Разработка схемы статей затрат и ведение затратных операций. Обучение основным отчетам по товарам и финансам. Анализ дебиторской задолженности, прогнозирование приходов и расходов денежных средств.
Ж. Настройка техники на оптимальную работу с пакетом.

Проведение ревизии склада (инвентаризация) – четкое определение остатков, выставление долгов по поставщикам, покупателям и прочим клиентам.

Октябрь.
Обучение всех методам обслуживания данных программы (логика, сохранение, восстановления, ремонт). Обучение работе с Windows программами комплекса.
З, Н сложные нюансы оперативного учета (группы, множество, дублирование документов, специализированная печать документов). Обучение навыкам «правильной» работе с программой.
Н – извлечение из программы «черно-белой» информации, построение основных бухгалтерских отчетов.
В, Н – сложные аналитические отчеты, технологии групп, системной метки, разделение товаров и клиентов по категориям.
Ж. Рекомендации по обучению менеджеров. Учат В и Н.

Ноябрь.
Обучение всех методам экспорта данных в электронные таблицы и глубокий с их помощью анализ информации.
Н, Ж. Решение всех вопросов бухгалтерского учета.
В, Н. Исправление ошибок ведения данных. Ведение основных средств и материалов (начиная с любого периода).
В. Все системы заказов товаров и планирования поставок.
Ж. Доработка программы под требования В, Н.

Уже можно будет оценивать правильность решения о приобретении программы.

Декабрь.
Обучение всех «сложным» оперативным и аналитическим возможностям пакета (динамическая отчетность, группирования документов, виртуальные документы, автоматизированные системы заказов и создания документов). Технология ABC/XYZ анализа и использования ее в оперативной работе. Использование «искусственных» схем работы с клиентами.
Доскональное изучение всеми Windows расширений пакета.
Ж. Доработка программы под требования В, Н.

Январь.
Доработки по программе и обучению с целью полного охвата технологий учета по фирме. Обучение системным методам обслуживания данных (можно обходится без Ж.). Обучение методам самостоятельной разработки технологий учета при помощи пакета.

Учитывая объем работы по внедрению на данный период (5 месяцев) предполагается оплата по х.000 в месяц, начиная с начала сентября. При «задержках» в реализации плана по вине фирмы продолжается выплаты по х.000 в месяц до полной реализации основного плата, по вине программиста – работает в режиме сопровождения (1.) до окончания реализации плана.

После этапа внедрения руководство выбирает оптимальный режим сопровождения (везде бесплатные телефонные консультации):

1. Постоянная поддержка и доработка программного обеспечения с еженедельным плановым посещением фирмы и при необходимости экстренным посещением в любое время (y.500 в месяц). Помощь и обучения по всему известному Ж. программному обеспечения компьютеров, настройка операционной системы и профилактические работы по обслуживанию компьютеров в рамках компетенции.
2. Ежемесячное обновление программы (z00 в месяц), экстренный вызов k00 рублей.
3. Обновление программ по требованию, но не чаще раз в квартал (k00 в месяц), экстренный вызов m00 рублей.

Август 20ХХ. ФИО
Домашний телефон хххххх, сотовый телефон хххххх.

От trdm_:

атрибутами

От lessonslearned:
 

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

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

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

В общем, где-то так…
Слабое звено – разработка, честно говоря сталкивался с разработкой “100S” (созвучное название) – один раз и разработчик реализовывал доработки довольно быстро…
По цене – если смотреть по прайсу компании с созвучным названием, то софт и лицензии – от 12000 до ~70000. Остальное – работы.

От lessonslearned:

Андрей Ж.,

Отпишу чуть позже, что понравилось/не понравилось :)

От s_ustinov:
 

lessonslearned

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

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

lessonslearned

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

То есть клиент начинает вести бухучет через 3 недели или через 2,5 месяца? Немного непонятно написано...

Я бы разбил на 2 проекта или этапа (начинать можно и одновременно)
1. внедрение стандартного функционала бухучета и отчетности. по этому этапу с общим временем (3 недели) в целом согласен, но скорее всего займет 4 недели - наверняка бардак со справочниками и остатками (ексель и непонятно кто и как ведет учет) - потребуется время на приведение к порядку. в данном проекте диагностика, разработка, тестирование и т.п. не нужны - принципиально только стандартный функционал и стандартные БП. то есть через месяц начинается работа в системе с бухучетом и параллельно обучение пользователей. если же ведение учета начнется в конце проекта - где время на обучение пользователей?
2. планирование ДДС... в принципе сама по себе разработка описанного функционала не очень сложная и займет примерно столько времени. а вот внедрение - не согласен.
основной вопрос - структура статей ДДС. часто на это все обращают мало внимания и при практической реализации спотыкаются. финансистам все привычно делить на операционные/инвестиционные/финансовые, но в данном случае ддс делается не для отчетности, а для планирования. и решить, как именно лучше структурировать - посевная, обработка ядохимикатами, уборочная ИЛИ гсм, запчасти, удобрения, аренда техники - очень непростой вопрос.
в приведенном плане очень вероятен результат, когда заказчик получит работоспособную систему, которую он не сможет использовать или которая не будет решать его потребности - а это провал проекта.
необходимо заложить минимум 2 недели на проработку структуры статей ДДС.

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

От seider:
 

lessonslearned, я конечно понимаю что сложно реализовать систему для микро предприятия, но я считаю, что нужно ёё сначала спроектировать в каком либо Case-средстве(программе) наподобие Rational Rose 2000 Enterprize Edition и/или Erwin, а потом непосредственно приступать к созданию
отчётных документов и программированию.Я конечно же не знаю, что вы считаете на этот счёт, может моё и Ваше мнения совершенно расходятся, но это лично моё мнение.
С уважением Seider

От lessonslearned:
 

s_ustinov

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

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

s_ustinov

То есть клиент начинает вести бухучет через 3 недели или через 2,5 месяца? Немного непонятно написано...

Не принципиально. Изначально планировалось через 2,5 мес. Если хотите раньше – выделите два связанных проекта и получите запуск через 6 недель (2 недели тестирование на готовых кейсах + 1 неделю обучение).

s_ustinov

Я бы разбил на 2 проекта или этапа (начинать можно и одновременно)
1. внедрение стандартного функционала бухучета и отчетности. по этому этапу с общим временем (3 недели) в целом согласен, но скорее всего займет 4 недели

Пусть займет 4 недели. На конечный срок не влияет.

s_ustinov

- наверняка бардак со справочниками и остатками (ексель и непонятно кто и как ведет учет) - потребуется время на приведение к порядку. в данном проекте диагностика, разработка, тестирование и т.п. не нужны - принципиально только стандартный функционал и стандартные БП. то есть через месяц начинается работа в системе с бухучетом и параллельно обучение пользователей. если же ведение учета начнется в конце проекта - где время на обучение пользователей?

Бардак со справочниками решается за счет стандартного внедрения. Вы внедряете коробку, поэтому уже заранее знаете что именно вам нужно настроить. Вам нужны только значения настроек и справочников. Время на обучение пользователей – забыл, нужно добавить еще 1-у неделю. Можно с частичным наложением на тестирование и завершение проекта.

s_ustinov

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

Согласен, что не простой вопрос. На старте для выявления требований выделено 4 недели. Провала нет. :)

s_ustinov

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

Но ведь как-то же люди в с/х работают? Думаю, что и планирование осуществляют в том числе…