Реализация единой учетной системы холдинга (или "Как мы спасали мир")

19.10.15

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

Проект по переходу с одной учетной системы на другую даже для небольших организаций - достаточно серьезное событие. А как реализовать такой проект для холдинга (50+ юр. лиц)? Про наш опыт проведения именно такого проекта мы и попытаемся Вам рассказать. Детально описать в подобной статье всю реализацию проекта невозможно. Углубляться в технические дебри тоже не хочется, поэтому приводится общее описание проекта "в прозе". Главное, что есть чем поделиться с теми, кто хотел бы узнать общую логику реализации подобного проекта.

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

Постоянными участниками проекта были представители Департамента бухгалтерского учета (ДБУ), Финансовой дирекции (ФД) и (конечно же... фанфары, шарики и конфетти...) Департамента информационных технологий (ДИТ).


Основные задачи участников:

- ДБУ - слушать, спрашивать, беспокоиться и понять "как же дальше жить" с точки зрения ведений бухгалтерского учета; получить представление о том, что нужно сделать/подготовить для реализации проекта, а также как все это сделать;

- ФД - формально - это флагман по организации ВСЕГО учета, поэтому в задачи входило все что касается переноса учета (не в последнюю очередь управленческого), "перенос" бизнес-процессов на новые рельсы, курирование проекта;

- ДИТ (фанфары, шарики и конфетти... ну вы в курсе) - оценка, конусльтирование, планирование всего, что касается инфраструктуры, учета (с точки зрения ведения его в системах 1С) существовавших и "перспективных" учетных систем, ну и, само собой, требуемой разработки;

 

Что мы имели в начале проекта?

- холдинг, в котором 50+ юридических лиц с различными видмами деятельности (услуги, торговля) и системами налогообложения;

- 50+ отдельных учетных систем бухгалтерии (70% БП3.0; 15% БП 2.0; 5% Аренда на БП 3.0);

- различия в подходах ведения учета и НСИ в различных системах бухгалтерии

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

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

- необходимость поддержки 50+ систем 1С;

 

Вот она, рыба моей мечты!

Изначально под основу для единой учетной системы рассматривались:

- УПП 1.3 - с точки срезния ведения бухгалетрского учета вопросов не было, но сравнивая наработки собственной управленческой системы пришли к выводу, что потребуется слишком много ресурсов для переноса и "заточки под себя"; кроме того, блок производства будет просто балластом (переплачивать, понятно, не хотели);

- ERP 2.0 - опять же, нет вопросов к бухгалтерии; как система для управленческого учета по ряду причин подходила больше, но опять же потребовала бы доработки; производство также было лишним;

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

Для сторонней оценки проекта, да и в целом как вполне возможный (не наиболее вероятный) вариант его реализации были привлечены сторонние компании, специализирующиеся на проектах внедрения учетных систем на платформе 1С. От привлечения сторонних компаний в итоге отказались в первую очередь из-за не устроившей оценочной стоимости проекта. Надо сказать, что факт отказа от привлечения сторонних компаний не добавил оптимизма внутренним участникам проекта ("говорите за себя, вы - ленивые тыжпрограммисты", сказали бы нам ДБУ и ФД), т.к. перспектива быть не просто неблагодарными зрителями, а самыми что ни на есть активными участниками, слегка пугала удручала.

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

 

Первые "кирпичи".

Первая сложность, с которой мы столкнулись - системы Управление Холдингом еще не было, пощупать, покрутить нечего, в наличии только презентация и надежда на светлое будущее. Существенным допущением, было то, что бета-релиз должен был на тот момент выйти через пару месяцев, а рабочий релиз только к концу года (2014). Впрочем, это не помешало бы уволить всех к чертям в случае провала. Поэтому на тот момент основные усилия были направлены на подготовку и планирование объединения данных нескольких десятков несвязанных между собой бухгалтерских систем.

В итоге первый бета-релиз мы получили только через пару месяцев, а первый рабочий релиз вышел еще через 3-4 месяца. Тестовый перевод баз нескольких организаций на бета-релиз УХ заставил понервничать (описание логики перевода приведено ниже), т.к. при "накатывании" новой конфигурации на базу выдавались критичные ошибки, связанные с измененными владельцами справочника "Банковские счета" - формально владельцы не изменились, но, видимо, из-за отличия внутренних идентификаторов метаданных система валилась в ошибки. Хоть на тот момент проблему решили (танцы с бубном, выгрузки/загрузки и т.д.), она не воспроизвелась в первом рабочем релизе, поэтому достаточно гладко отработала схема перехода.

Следующим интересным моментом, который предстояло решить - как модифицировать большую систему, и при этом регулярно и с минимальными трудозатратами ее обновлять на официальные релизы. На помощь, сама того не подозревая, пришла компания 1С, вовремя анонсировавшая Расширения! Опять же решение об их использовании было принято и утверждено ДО публикации релиза платформы с данным функционалом - это второе существенное ограничение по проекту ("ну, теперь точно уволят", подумали мы). Время ожидания нужного релиза платформы, которое к слову составило около 3 месяцев, было потрачено на поиск вариантов доработки типовой конфигурации с минимальным изменением самого типового функционала (для обеспечения простоты дальнейшей поддержки всей системы). Основные принципы, которые используются:

- подписки (спасибо кэп);

- по максимуму консолидация "добавленного" кода в свои общие модули;

- отчеты/обработки/регламентные задания через "Дополнительные отчеты и обработки" БСП;

- при необходимости добавления реквизитов к типовым объектам - хранение значений в регистрах сведений и программный вывод соответствующих элементов в формы через Расширения;

- использовать префиксы для новых объектов, комментировать код;

Безусловно, совсем без доработки типового функционала порой не обойтись. Главное сделать это не только верно с точки зрения работоспособности, но и с точки зрения дальнейшей поддержки.

 

Сибирский цирюльник. (Н.С. Михалков All Rights Reserved)

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

Как привести в порядок НСИ? Это надо начинать делать еще в "старых" системах. После слияния данных нескольких баз мы получим дубли почти в каждом справочнике системы. И если в ряде случае ну и хрен бы сним для дальнейшего ведения учета это не имело значения, то в большинстве своем представляло проблему: бардак и дубли по валютам, контрагентам, физлицам, статьям, номенклатуре и т.д. и т.п.. Задача вполне решаема (обработок куча, в т.ч. и типовые), но при условии, что для свертки дублей в данных будут уникальные признаки, по которым эти самые дубли можно идентифицировать и свернуть. Однако, здравствуйте зачастую бухгалтер "в своей зоне ответственности" ведет учет так, как считает правильным. Именно это мы имели на тот момент - массивы "не причесанных" данных. По этому поводу в ДБУ улетела задача "Причесать!". Забегая вперед скажу, что расческа у них была не очень, многое ковыряли по факту.

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

По большинству данных при свертке используется стандартный принцип "на кого больше ссылок, тот и крут";

 

Мы предполагаем, а...

 Общий план работ был примерно следующий:

1. Этап - данные бухгалтерии:

- ДБУ к концу года максимально оперативно закрывает год по юр. лицам (в итоге небольшая часть организаций с малым оборотом была закрыты еще в декабре 2014);

- готовые базы юр.лиц передаются в ДИТ для переноса в новую систему;

- на период переноса работа в этих базах блокируется;

- после переноса данных в новую систему любые изменения закрытого периода по организации ДБУ переносит вручную в виде корректировки операций ввода начальных остатков;

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

- в какие даты уже не нового 2015 года какие организации будут переноситься;

- какое количество этих организаций с учетом специфики учета и объема данных можно перенести за одну итерацию; 

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

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

 2. Этап - управленческий учет:

- переход от "старой" управленческой системы к новой;

- перенос необходимых первичных данных НСИ;

- оперативная корректировка данных/функционала;

 3. Этап - поддержка:

- обеспечение параллельной работы ДБУ и ФД;

- по необходимости дальнейшее причесывание данных;

 

Поехали!!!

В УХе в качестве подсистемы бухгалтерского учета используется БП КОРП, поэтому, как многие уже и без нас догадались, чтобы перенести данные бухгалтерии в УХо нам потребовалось:

- обеспечении соответствия релиза бухгалтерской системы и релиза подсистемы БП в УХе;

- "накатить" на бухгалтерскую систему конфигурацию УХа;

- выполнить минимальный набор технических операций;

- перенести данные через стандартную "Выгрузку/Загрузку данных XML между идентичными конфигурациями" в новую единую систему;

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

- по вышеописанной схеме готовились файлы выгрузок по очередной порции организаций;

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

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

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

- по результатам сверки данных со стороны ДБУ выполнялись дополнительные корректировки данных;

Конечно, приходилось так же учитывать и различие между конфигурациями БП исходных систем и БП КОРП в УХе. В основном это массовое дозаполнение реквизитов и аналитик учета.

 

Не подведу - сказал прораб народу, и не подвел, ни свет, ни газ, не воду!!!

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

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

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


Спасибо, что ознакомились с нашим опытом. Готовы внести уточнения или более подробно раскрыть моменты, которые будут интересны.


проект ух Управление Холдингом ухо внедрение обмен перенос данных планирование

См. также

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

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

28.10.2024    751    0    paalferov    1    

5

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

Управление любым проектом заключается в систематической работе по снижению рисков. Чтобы избежать бесконечного цикла итераций согласования и приемки работ, нужно фиксировать границы проекта в Уставе, обозначать зоны ответственности и внимательно составлять план-график. О практическом опыте избегания рисков на проекте на конференции расскажем в статье.

09.09.2024    620    0    user1231217    1    

4

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

Бывают ситуации, когда обновление изрядно измененной 1С с большой базой не составляет особых трудностей — до определенного момента. Таким моментом становится, например, переход на новую подредакцию. После чего приходит понимание, что обновлять, как раньше — уже не получается и нужно что-то менять.

12.07.2024    1152    0    1c-izh    1    

5

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

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

28.05.2024    654    0    Radio_Analyst    0    

4

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

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

07.02.2024    3099    0    izybaevda    18    

16

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

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

20.12.2023    4939    0    1СERP    21    

31

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

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

12.09.2023    1772    0    chat007    0    

5

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

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

01.09.2023    2390    0    olegminkov    2    

10
Вознаграждение за ответ
Показать полностью
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. mmoozzgg 19.10.15 08:55 Сейчас в теме
Познавательно. А сколько "1Сников" участвовало в проекте?
4. Lars Ulrich 625 20.10.15 15:42 Сейчас в теме
(1) mmoozzgg, в проекте участвовало три 1Сника, у каждого из которых была некая "специализация" по реализуемым задачам:
- курирование блока БУ;
- курирование блока УУ;
- ПМ нахлебник;

(2) ILM, да, все верно - эта схема вполне применима, но мы руководствовались следующими соображениями:
- пока ДИТ готовит очередную порцию данных для переноса, ДБУ продолжает работать с уже перенесенными данными (создавать документы, записи справочников), увеличивая объемы последующей "чистки". Нам показалось проще сделать такую предварительную "чистку" по всем возможным данным сразу, т.к. и объемы меньше, и управлять ими в тот момент проще, т.к. мы (ДИТ) имеем к ним неограниченный монопольный доступ до момента загрузки в рабочую базу.
- в рамках предварительных тестовых переносов наша инфраструктура (не будет углубляться, что именно было причиной: платформа, сервера и т.д.) не позволила нам выполнить работу по схеме "сначала все переносим, потом все чистим" - при удалении дублирующихся элементов (читай замене ссылок на эталон) мы неизменно получали крах системы.

(3) Dem1urg, в целом надо сказать, что система достаточно стабильна. В первых релизах действительно сталкивались со сложностями, но либо самостоятельно находили решения/пути обхода до выхода нового релиза, либо получали информацию об устранении ошибок от службы поддержки.
Оговорюсь, что мы пока не на 100% используем функционал системы, но используемые блоки, как уже отметил, стабильны.
2. ILM 241 19.10.15 10:12 Сейчас в теме
Можно было после загрузки каждой базы БУХ Корп основные НСИ такие как классификаторы и справочники, поправлять обработкой и грузить следующие. Разные юрлица позволяли бы разделить сразу остатки и временно их не трогать.
3. Dem1urg 392 19.10.15 12:35 Сейчас в теме
Насколько вообще "стабильна" УХ? Много ли ошибок в "типовом" функционале?
Сами к ней присматриваемся, но пока "боязно" запускать такое в промышленную эксплуатацию.
5. Кузьмич 188 21.10.15 09:41 Сейчас в теме
Это была реклама конфигурации УХ?
15. Lars Ulrich 625 22.10.15 11:08 Сейчас в теме
(5) Кузьмич, если это выглядит как реклама УХ, то подумаем о выставлении счета 1С :)

(6) Кузьмич, условно сравнивая оценочную стоимость проекта со стороны франча и общую сумму затрат по ЗП внутренних участнико проекта за 12 месяцев, получаем положительную разницу минимум в 2 раза. Временные затраты сравнить сложнее, т.к. условия реализации внешнего подрядчика и внутренних исполнителей разные: первые погружены только в проект, вторые параллельно ведут текучку. Так же, возможно, франч и уложился бы в озвученные сроки, но как показывала моя личная практика, озвученное время можно смело умножать на 1.5-2.

(8) Зеленоград, подумаем про статистику :)

(9) Зеленоград, не совсем понял.. речь идет об унификации НСИ еще в исходных базах? если так, то мы не стали этого делать по двум причинам:
- ковырять данные старых баз, где содержались данные БУ за несколько лет не решились, т.к. по ним должны были формировать годовую отчетность, плюс они своего рода эталонные, пусть и проблемные и даже кое где с "хвостами" в учете. В нашей схеме мы имели возможность обратиться к ним и либо что-то восстановить, либо убедиться в корректности переноса данных в общую базу.
- учитывая количество баз мы прикинули, что затратили бы много больше времени на разработку, реализацию и выполнение предварительной унификации НСИ по ним.

(10) zarius, этот минус, исключительно чисто гипотетически, можно решить арендой инфраструктуры и выводом БД за пределы длины рук органов ;)

(11) Kamikadze, количество сеансов не большое - порядка 200. Ни визуально, ни по встроенным замерам APDEX проблем с производительностью нет.

(12) Kamikadze, все довольны :)

(13) sveta66rss, функционал по обменам с внешними системами действительно есть: 7.7, 8.0, 8.1, 8.2, 8.3, ADO. Конфигурация в данном случае вторична, т.к. отражение данных настраивается.

(14) sveta66rss, обновления выходят обычно раз в месяц, реже два.
16. zarius 158 22.10.15 13:44 Сейчас в теме
(15)
Выносить БД в облако - реально для небольшой организации с небольшой активностью.
Вот в Вашем случае реально было бы увести эту БД в облако?
19. Lars Ulrich 625 24.10.15 18:59 Сейчас в теме
(16) zarius, скажем так - смею утверждать, что это вполне реально :)

(17) andrey3d,
1. рабочая система прошла все официальные релизы от 1.0 (на нем и стартовали) до 1.1. Бету использовали для первичного ознакомления и тестов.
2. под УУ понимались подсистемы бюджетирования, казначейства и финансовой отчетности (от внутренней до в перспективе МСФО).
3. "внешних" систем пока нет, поэтому функционал не задействовали.

(18) echo77, не совсем так. ДИТ не планировал все за всех, и тем более не определял учетную политику. Характеристики и параметры учета определялись профильными подразделениями. ДИТ перекладывал "хотелки" на рельсы систем 1С.
Например: ФД говорит: "Необходимо, чтобы в новой системе можно было заводить помесячные бюджеты в рамках Проектов и ЦФО"; ДИТ гладит шнурки представляет системы, которые позволяют это сделать, при этом уточняется: с доработками или без, какие ресурсы нужны для реализации и т.д.
Итоговое решение об использовании системы у нас принималось рабочей группой проекта, в которую входили представители всех участников.
6. Кузьмич 188 21.10.15 09:46 Сейчас в теме
От привлечения сторонних компаний в итоге отказались в первую очередь из-за не устроившей оценочной стоимости проекта

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

Более важно качество работ аутсорса. В 80% случаев (то бишь качество франчайзи) это именно "попадалово на деньги".
7. pbabincev 133 21.10.15 10:04 Сейчас в теме
Класс!
Легко и интересно читать, ёмко изложено.
Спасибо, автор!
8. Зеленоград 21.10.15 10:58 Сейчас в теме
Молодцы. Теперь расказывайте статистику ошибок в данных, в программе, различия между плановыми и фактическими трудозатратами.
9. Зеленоград 21.10.15 11:00 Сейчас в теме
Вариант "Сначала синхронизировать и дополнить ключевую НСИ" не применялся? Почему? Это можно было запустить вторым этапом - параллельно в основной работтой пользователей, заодно приучая их к работе в общей БД.
10. zarius 158 21.10.15 11:53 Сейчас в теме
С точки зрения логичности, прозрачности, стандартности, поддержки и прочее - объединение всех фирм холдинга в одной базе - вопрос нужный и необходимый. Но есть минус, который зачастую сводит на нет все преимущества - когда БД одна, при изъятии соответствующими органами, в их руки попадает цельная картина всего что в холдинге происходит.
11. Kamikadze 46 21.10.15 16:59 Сейчас в теме
Какое количество пользователей одномоментно работает в системе? Проводился ли анализ производительности?
12. Kamikadze 46 21.10.15 17:00 Сейчас в теме
И еще, как вообще конфигурация себе показала с точки зрения формирования отчетности для руководства?
13. sveta66rss 22.10.15 08:54 Сейчас в теме
Возможна выгрузка данных для анализа из всех конфигураций? из 7 торговли, 8,2 бух, зуп?
14. sveta66rss 22.10.15 08:55 Сейчас в теме
Как часто происходит обновление?
17. andrey3d 82 22.10.15 18:18 Сейчас в теме
1. Какой релиз УХ в итоге использовали ( бета, 1.0, 1.1 )? По описанию не совсем понятно.
2. Перенос управленческого учета в УХ? А что в проекте считалось управленческим учетом?
3. Функционал "Консодидации" в УХ задействовали?
18. echo77 1908 24.10.15 16:44 Сейчас в теме
Не пойму какого черта ДИТ все планировал за всех? Решение о том какую учетную политику вести, как вести справочники тоже ДИТ предлагал?
Кто же выносил предложения и решал какая новая система должна быть?

Я спрашиваю не просто так, нам предстоит объединить две немаленькие организации в результате слияния юр.лиц.
20. HitGroove 50 26.10.15 10:23 Сейчас в теме
Ни какой конкретики... 50+, 3 месяца... Ни одного слова о количестве работающих пользователей, планировании вычислительных мощностей. Как то не понятно когда закончили, если первые расширения вышли 29.04.15. Сколько человек принимало участие в проекте, сколько программистов, сколько представителей заказчика, какой бюджет проекта, по какой методике велась разработка/доработка, как осуществлялся контроль за выполнением работ. Коль уж "В прозе" тогда надо было бы начать: "Звездное небо медленно качалось над мной, ДБУ что то бормотал рядом, а мои мысли выраженные в переживаниях о скором переходе на новую программу не давали покоя."))
22. Lars Ulrich 625 10.11.15 11:01 Сейчас в теме
(20) HitGroove, поработаю над стилем ))

(21) pro-rok, из документации были первичная презентация на тему "как есть и как будет", общий план проекта, детальные поквартальные планы и всякая мелочь, которая в большинстве "размазана" по почтовой переписке. Думаю, можно сказать, что с документацией не заморачивались. По стоимости оценка была около 10 млн. руб.
21. pro-rok 297 09.11.15 07:55 Сейчас в теме
Отличная статья, кратко и информативно.
Есть пара вопросов, была ли рабочая документация по проекту (интересно что в себя включала) или вы этим не заморачивались. И если не секрет сколько франч попросил за подобную работу?
Оставьте свое сообщение