УПП: Хроники МЕГАпроекта

Публикация № 166856

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

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

В апреле 2012 завершился сложный проект комплексной автоматизации в компании «Световые технологии». Проект начался в конце мая 2011, с 10 января все уже работали в новой базе, полностью отказавшись от старых систем. Функциональные требования у клиента были очень высокие, что не сочеталась со  сроками начала эксплуатации, которые планировались по проекту. До нас заказчик уже начинал сотрудничать с двумя компаниями, которые после экспресс- обследования отказались от проекта. Для нашей команды (http://делаемпроекты.рф/) это был профессиональный вызов.

В результате проекта типовая конфигурация, взятая за основу, была переработана процентов на 40. Все реализовано в 1С:УПП на РАУЗе и интегрированной в нее конфигурации БИТ:Финанс. Конструкторская и технологическая документация ведется в 1С:PDM, между которой настроен автоматический обмен с 1С:УПП. В базе одновременно работает около 650 пользователей. Около 300 внутренних, остальные ключевые клиенты. Клиенты физически работают в базе через web- интерфейс, реализованный на управляемых формах.

Максимальное количество одновременно работающих специалистов с нашей стороны на проекте 23, количество сотрудников, принявших участие в проекте 32.

Описание того, что сделано http://делаемпроекты.рф/project/6/

Пресс релиз по проекту http://v8.1c.ru/news/newsAbout.jsp?id=8273

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

  1. Управление заказами
  2. Управление оперативным производством
  3. Учет затрат (РАУЗ)
  4. Сервисные функции

Блок «Управление заказами»

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

В корректировках все старые реквизиты начинаются со слова «Старое/ый» или буквы «(С)». Если значение в старой колонке не равно значению в новой, то при проведении документа выполняются корректирующие движения. Сторно старых значений и приход новых.

нет

нет

нет

нет

Блок «Производство»

Блок был значительно переработан, добавлено много новых документов, обработок и отчетов. Из наиболее ключевых объектов в блоке можно выделить:

1. Документ «План производства» (типовой).

Добавлены сервисные функции автоматического заполнения табличной части по правилам MRP II (новый реализованный механизм).

нет

2. Документ «Корректировка планов производства» (новый).

Используется для актуализации планов производства.

нет

3. Документ «План производства по дням недели» (новый).

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

нет

4. Документ «Заказ на производство» (типовой).

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

нет

нет

нет

5. Документ «Корректировка заказа на производства» (типовой).

В документе добавлены сервисные функции и возможность корректировать заказы на производство с учетом технологии производства.

нет

6. Документ «Разрешенная замена».

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

нет

7. Документ «Карта замены».

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

нет

8. Документ «Отчет производства за смену» (типовой).

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

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

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

нет

нет

Блок «Учет затрат (РАУЗ)»

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

нет

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

В механизмы расчета себестоимости в дополнение к типовым аналитикам были добавлены:

  1. Организация,
  2. Счет управленческого учета,
  3. Статья оборотов (взамен справочника «Статьи затрат»),
  4. Аналитика 3-го уровня (произвольная аналитика для учета затрат).

Регистры по учету затрат, которые были модифицированы:

нет

Пример документа с добавленной аналитикой по управленческому учету, используемой при отражении по регистрам затрат:

нет

нет

В документе «Поступление товаров и услуг» добавлена возможность относить стоимость услуг на себестоимость товаров без ввода дополнительного документа «Поступление доп. расходов», что требуется в типовом функционале:

нет 

В документе «Получение услуг по переработке» добавлена возможность распределять стоимость услуги на выпущенную продукцию переработчиком сразу при проведении документа. В типовом функционале для этих целей используется отдельный документ «Распределение прочих затрат».

Реализованы механизмы по расчету плановой себестоимости продукции с «разузлованием»:

нет

нет

нет

Блок «Сервисные функции»

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

нет

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

нет 

Следующая обработка за указанный период меняет во всех документах по выбранному виду номенклатуры или номенклатуре счета учета УУ, БУ, НУ.

нет

В текущей статье я изложил очень малую функциональную часть от всего что было реализовано на проекте. За кадром остаются многие вопросы, потому как техническая сторона на проекте не самая большая. На мой взгляд, одна из интересных тем «Управление проектом». После нового года планирую посвятить этому отдельную статью, в которой опишу практический опыт по данному проекту. Теорию писать не вижу смысла, ее и так много, а вот как на реальном большом проекте собирали команду, по какой технологии запускали проект (использовали элементы Agile), как организовывали команду внутри, взаимодействовали с командой Заказчика и с какими сложностями сталкивались, вот это должно быть интересно.

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

Жду Ваших предложений, чтобы определить круг интересов аудитории.

----------------------------------------
С уважением, Антон Щекачев

Технический руководитель проекта
Офис «м. Савеловская» (Москва) - http://делаемпроекты.рф/
Компания «Первый БИТ» (1С:Бухучет и Торговля)

75

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. krolya 281 19.12.12 19:12 Сейчас в теме
От себя добавлю частично новую информацию, что:

Проект вошел в ТОП-30 крупнейших проектов на 1С:Предприятии (http://v8.1c.ru/applied-solutions/top500.jsp)
Проект номинирован на премию "Проект года" сообщества Global CIO.

Вступить в сообщество можно здесь (http://www.globalcio.ru/registration/).
Проголосовать за наш проект можно здесь (http://www.globalcio.ru/projectoftheyear/projects/#region/3/project/128)
2. Модератор раздела Alraune 19.12.12 19:55 Сейчас в теме
Вопрос к Вам как специалисту. В УПП (без РАУЗ) есть возможность рассчитать себестоимость (полную, с учетом общепроизводственных и общехозяйственных затрат) в разрезе ЗАКАЗОВ НА ПРОИЗВОДСТВО?
3. ASchekachev 119 19.12.12 20:29 Сейчас в теме
(2) Alraune, да можно, причем режим работы конфигурации РАУЗ или партионный учет (ПУ) значения не имеет.
Для того, чтобы рассчитать себестоимость по заказам на производство, нужно во всех документах по отражению затрат явно указывать к какому заказу на производство относится затрата.

К примеру, Вы хотите посчитать себестоимость в разрезе заказов на производство и отражаете затраты через документы:

1. Поступление товаров и услуг
2. Прочие затраты
3. Требование накладная
4. и т.д.

В этом случае во всех этих документах нужно явно указывать заказ на производство к которому относится затрата.
Если к примеру, сумму в 1 000 руб нужно разделить между заказами №1 и №2, то нужно заносить две строки, одну на 150 руб. по заказу №1, другую на 850 руб. по заказу №2 или в другой пропорции.

Если Вы хотите сумму затрат распределить между всеми заказами на производство в разрезе которых отражали выпуск в течение месяца, то заказ на производство можно не указывать в документах при отражении затрат.

Далее, если у Вас был выпуск продукции по заказам на производство и затраты были собраны в разрезе этих заказов, то документ расчет себестоимости выпуска (РСВ) распределит по заданной базе распределения эти затраты в разрезе заказов, если затраты были собраны без заказов, то РСВ распределит их на все выпуски по всем заказам на производство.

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

Аналитика затрат при выпуске продукции документом "Отчет производства за смену" (ОПЗС) указывается на закладке "Продукция" в колонке "Заказ затраты". Для того, чтобы эта колонка появилась нужно в ОПЗС по кнопке "Настройка" установить флажок "Использовать заказы".
4. Модератор раздела Alraune 19.12.12 20:35 Сейчас в теме
(3) спасибо. С прямыми затратами оно было понятно, а вот с косвенными. Я правильно поняла, что если мы приходуем электроэнергию... или начисляем зарплату администрации ... или амортизацию ... и у нас в работе несколько заказов на производство (ну штук десять-двадцать), один будет сдан в этом месяце, другой в следующем, третий через несколько месяцев, остальные через полгода? Это надо вручную рассчитать базу распределения и проставлять ее в каждый документ? Тем более в таких документах, как "Начисление зарплаты", по-моему, вообще невозможно указать заказы на производство
7. ASchekachev 119 19.12.12 21:43 Сейчас в теме
(4) Alraune, то что я описал это как раз про косвенные. Вы правильно подметили в типовой в документе отражения з/п в регл. учете нельзя указать заказ на производство. Им можно только отразить затраты без заказа. Но это легко лечится доработкой.

В Вашем случае вижу два варианта.

Первый.

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

Второй.

К примеру, у Вас есть N заказов и одна затрата по Электроэнергии, но эту затрату нужно распределить пропорционально базе распределения не на все N заказы, а только на избранные. В этом случае при отражении такой затраты придется разделить суммы, которые пойдут на каждый из заказов. При РСВ уже затраты в рамках заказа будут распределены по заданной базе распределения по другим аналитикам (номенклатурные группы, спецификации, продукция)

Типовыми механизмами эта задача решается, но не сильно удобно. Тут как правило разрабатывают различные сервисные процедуры по распределению сумм, указанных в таб. части по нужным аналитикам и нужным правилам.
13. Модератор раздела Alraune 19.12.12 23:17 Сейчас в теме
(7) Антон, спасибо Вам за ответы :)
5. tango 488 19.12.12 20:39 Сейчас в теме
по первому глазу плюса
но таки не видно 20 человек 12 месяцев...
что оставили за кадром?
Bukaska; kolya_tlt; comol; +3 Ответить
8. ASchekachev 119 19.12.12 21:55 Сейчас в теме
(5) tango, за кадром осталось 11397 человеко-часов большого командного труда.

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

Если интерес обозначится к конкретным темам, то готовы ответить на вопросы в развернутом виде, возможно с приложением отдельных документов с проекта.
9. tango 488 19.12.12 22:10 Сейчас в теме
(8) интересно очень. но, тьфу-тьфу, интерес "академический". хочется, чтобы кроме обновления практически типовых бухгалтерий не интересовало ничего как можно дольше.
вообще, реально рад за вас. приятно, что работа где-то делается уже
удачи :)
6. sarun 19.12.12 21:19 Сейчас в теме
Вопрос по формированию заказов через веб-приложение. У вас как я предполагаю реализовано через https есть ли подвисания при работе стольких пользователей в защищенном режиме?
47. AErzikov 20.12.12 11:58 Сейчас в теме
(6) bagaev, Здравствуйте! Меня зовут Ерзиков Андрей. На данном проекте я выполнял роль технического руководителя по блоку оперативного учета. По вопросу о вэб доступе: доступ организован по http, проблем с зависаниями при работе web ползователей нет. Единственное были жалуобы от тех пользователй, у кого очень низкая скорость соединения, и долгий пинг до москвы.
48. tango 488 20.12.12 11:59 Сейчас в теме
(47) AErzikov, снабжение считается оперативным учетом?
69. AErzikov 20.12.12 13:58 Сейчас в теме
(48) tango, Да, считается, готов ответить на вопросы.
71. tango 488 20.12.12 14:11 Сейчас в теме
(69) AErzikov, спасибо

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

для начала хотелось бы уточнить обстановку:
вы работали с московской головой или снабжение конкретного производства?
насколько в холдинге централизован закуп?
73. AErzikov 20.12.12 14:16 Сейчас в теме
(71) tango, мы работали с отделом закупки, который обеспечивает производство в России, закупка в рамках всего холдинга не централизована.
77. tango 488 20.12.12 14:40 Сейчас в теме
(73) AErzikov, все интересней и интересней:
обеспечивает производство в России
vs
не централизована


есть несколько предприятий по РФ, объединены собственником
у собственника с Москве есть управляющая структура, с которой вы и работали
на предприятиях, каждом из них, есть свои маленькие королевства в королевстве - отдел снабжения
и есть подразделение московской структуры, которая обеспечивает...

может быть, мы по-разному понимаем термин "централизация"?
80. AErzikov 20.12.12 15:16 Сейчас в теме
(77) tango, в общий холдинг входят предприятия не только в РФ, в РФ есть один завод в Рязани + управляющая структура в москве. Основная закупка ведется из Москвы, но часть закупается из Рязани. И московские и рязанские пользователи работаю в одной базе. При данной структуре я бы не назвал закупку совсем централизованной.
82. tango 488 20.12.12 15:25 Сейчас в теме
(80) AErzikov, понял. просто я сталкивался с другой схемой: звезда, несколько лучей-предприятий. до 80% (номенклатуры) закупок - только через московского поставщика (отсюда забавная фишка - синхронизация справочников...).

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

**
ок. следующий вопрос - план производства есть? снабженцы его используют как руководство к действию?
и еще, от туда ж: при отпуске материала в цех виза снабжения требуется?
83. AErzikov 20.12.12 15:28 Сейчас в теме
(82) tango, есть единоначальник.
84. tango 488 20.12.12 15:31 Сейчас в теме
(83) AErzikov, извините, я дописал (82)
95. AErzikov 20.12.12 17:21 Сейчас в теме
(82) tango, да есть план производства и это руководство к действию для снабженцев. От плана производства до заказов поставщикам процесс организован следующим образом:
Есть специалный "интерактивный" отчет "План закупок", он берет данные из планов производства, текущие остатки, и из созданного регистра сведений "План закупок".
Почему он интерактивный: он позволяет непосредственно из отчета на основании остатков на складе, планов производства, методов пополнения запасов (варианты на тему MRP) произвести расчет колличетва, которое необходимо закупить с периодичностью неделя. Далее менеджер вносит корректировки в рассчитанно количество, по каждой позиции после проверки количества фиксирует, что это плановой количество утверждено им. После того как план сформирован, непосредственно из отчета можно создать заказы поставщикам на выбраный период, с отборами по номенклатуре и поставщикам. Прикрепил изображение, как это выглядит в жизни.
Прикрепленные файлы:
97. tango 488 20.12.12 17:28 Сейчас в теме
(95) AErzikov, спасибо.
таки есть
сведений "План закупок"

что (как вычисляется количество), чем, кем туда пишется, с какой регулярностью?
**

да, и почему РС? у меня (был когда-то) накопления, оборотный
106. AErzikov 20.12.12 17:56 Сейчас в теме
(97) tango,
таки есть
сведений "План закупок"

что (как вычисляется количество), чем, кем туда пишется, с какой регулярностью?
**

да, и почему РС? у меня (был когда-то) накопления, оборотный


Данные в регистр сведений пишутся непосредственно из отчета.
При двойном клике на ячейке с планируемым количеством открывается форма редактирования кличества(95) после редактирования в ней данных и нажатия на кнопку "Заверить редактирование" данные пишутся в регистр.

Регистр сведений периодический, периодичность секунда.

Регистр сведений, т.к. если делать регистр накопления, необходимо к нему делать документ.
Документ "План закупок" пользователи не приняли бы, а делать все создания документов программно кажется не очень красивым варианом, а так каждое изменение - новая запись в регистре, хранится вся история редактирования, а актуальное состояние плана - срез последних.
107. tango 488 20.12.12 18:00 Сейчас в теме
(106) AErzikov, ну как бы да, см. (101)
101. tango 488 20.12.12 17:47 Сейчас в теме
(95) AErzikov, +(97) по ходу вы в этот отчет и регистр тупо загнали ексельную табличку.
у меня регистр складские и заказы поставщикам двигали
10. tango 488 19.12.12 22:33 Сейчас в теме
для снабженцев сильно настраивали?
(это функционал мне лично приходилось разбирать и собирать на крупном машиностроительном)
Прикрепленные файлы:
11. romansun 189 19.12.12 23:02 Сейчас в теме
Да, про управление процессом, организацию работы специалистов, agile было очень очень интересно почитать. Каким софтом пользовались - СУПы, баг-трекеры всякие.. Частота итераций. Была ли рабочая группа со стороны заказчика, чем она занималась?

Что с поддержкой, обновлениями, обучением?

Интересно, в общем, всё :)


А если по технической части, то можно было бы вот что спросить:

Какой объем базы? Количества строк в справочниках, регистрах.. Сервера? Дедлоки? Как организован процесс бэкапа?

По PDM-ной части: насколько большие сборки - сколько уровней вложенности, количество номенклатуры? Быстро ли обсчитывается на самых крупных сборках полный "состав изделия" с разузловкой - себестоимость, материальные ведомости, технологические ведомости?

Внедрялся ли какой-то поцеховой оперативный учет, маршрутные карты и пр.? Расчеты загрузки цехов?


Ну т.е., если одним словом - насколько крупное производство и быстро ли ворочается PDM с ним? :)

А вообще, 650 человек на PDM + УПП - да, это круто, поздравляю (знаю, что ацкий труд)!
Завидую по-хорошему немного.. ))
Bolik13; AnderWonder; +2 Ответить
23. tango 488 20.12.12 10:32 Сейчас в теме
в общем, господа коллеги, рекомендую прогуляться по указанным ссылам - интересно, познавательно, и, как указал коллега в (11), немножко завидно
28. Модератор раздела artbear 20.12.12 11:18 Сейчас в теме
Пока не увидел ничего нового/полезного из статьи, кроме рекламы своего труда и своих достижений :(
Ответы на вопросы в комментариях намного интереснее.
Самое главное - например, вопросы из (11) - не рассказано.
До получения более полной развертки статьи временно минусану :(
105. ASchekachev 119 20.12.12 17:52 Сейчас в теме
(28) artbear,

Пока не увидел ничего нового/полезного из статьи, кроме рекламы своего труда и своих достижений :(

Ответил, см (93). По производству отвечу завтра.
93. ASchekachev 119 20.12.12 17:07 Сейчас в теме
(11) romansun,

Да, про управление процессом, организацию работы специалистов, agile было очень очень интересно почитать. Каким софтом пользовались - СУПы, баг-трекеры всякие.. Частота итераций. Была ли рабочая группа со стороны заказчика, чем она занималась?


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

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

Что с поддержкой, обновлениями, обучением?


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

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

Для того, чтобы процесс был управляемый и было все однозначно (для нас, для Заказчика) была разработана небольшая функциональность (Реестр замечаний) доступная через Web для фиксации задач, замечаний и контроля их выполнения.
На первом этапе все поступающие задачи смотрел РП Заказчика, назначал им приоритеты, затем каждый ТРП внутри приоритетов назначал свои приоритеты и распределял между исполнителями (нашими, Заказчика). При выполнении задачи, сотрудник отмечал в реестре, что сделано, ТРП проверял качество и функциональность решения.
Если возникали критичные неотложные задачи, то их выполняли сразу, а потом отражали в реестре замечаний.

Реестр замечаний получился такой:
1. Справочник "Задачи и замечания"
2. Отчет по этому справочнику
3. Документ "Выполнение работ по задачам" - его за неделю вводили наши сотрудники, фиксируя время затраченное на выполнение задач.
4. Отчет "Выполнение работ по задачам" - его смотрели ТРП и РП Заказчика, в конце месяца этот отчет передавался в оформленном виде Заказчику и на его основании Заказчик производил оплату работ.

Скриншоты прилагаю.

На этапе старта проекта все ТРП понимали, что база должна быть обновляемой. Был сделан небольшой документ с требованиями к разработке. На этапе сдачи работ ТРП проверяли работы в т.ч. и с этой стороны.
Часть документа прилагаю.
В результате проекта база получилась обновляемой. Наш специалист обновляет ее за 2 недели.
- Сначала снимает cf-к с базы хранилища (Рабочая база обновляется раз в день из хранилища в конце дня)
- Обновляет его до нужного релиза (тестирует на копии базы результаты)
- Снимает второй раз cf-к с базы с харнилища(чтобы учесть все доработки, которые появляются за время между первым получением cf-ка)
- Сравнивает первый cf-к со вторым, выявляет отклонения, переносит их в подготовленный cf-к для обновления.
- Обновляет рабочую базу
- Утром все работают в обновленной базе.

Какой объем базы? Количества строк в справочниках, регистрах.. Сервера? Дедлоки? Как организован процесс бэкапа?

На этот вопрос ответит Андрей Ерзиков.

По PDM-ной части: насколько большие сборки - сколько уровней вложенности, количество номенклатуры? Быстро ли обсчитывается на самых крупных сборках полный "состав изделия" с разузловкой - себестоимость, материальные ведомости, технологические ведомости?


У нас всего четыре уровня вложенности, количество производственной номенклатуры в PDM около 15 000.
С разузловкой в PDM проблем нет, вложенность не большая.
В рабочей базе УПП и везде, где нужно использовать разузлование мы исходили из тех ограничений, что у нас ограниченный уровень вложенности и везде где нужно было выполнять разузлование делали это одним запросом.
Текст запроса и схемы СКД прилагаю.

Внедрялся ли какой-то поцеховой оперативный учет, маршрутные карты и пр.? Расчеты загрузки цехов?

Да внедрялся, отвечу на этот вопрос завтра. Есть еще вопросы от других участников, поэтому после ответа на них вернусь к этому. Он не быстрый. Скорее всего к этому моменту все согласую с Заказчиком и по блоку "Производство" выложу отдельные части инструкций с проекта, чтобы не переписывать то что уже есть.

Ну т.е., если одним словом - насколько крупное производство и быстро ли ворочается PDM с ним? :)

Производство я бы назвал среднее, PDM с ним справляется нормально. Сам проект крупный, т.к. решалось очень много функциональных задач и работает большое количество пользователей.
Прикрепленные файлы:
Требования к разработке (частично).docx
Разузлование (примеры).rar
kuntashov; romansun; +2 Ответить
99. AErzikov 20.12.12 17:45 Сейчас в теме
(11) romansun,
Какой объем базы? Количества строк в справочниках, регистрах.. Сервера? Дедлоки? Как организован процесс бэкапа?

В данный моент база занимает около 70 Гб, Но процентов 30-40 от объема, это прикрепленный файлы (используется стандарный механизм прикрепления файлов).
Количество элементов в справочниках:
Номенклатура - около 23000
Контрагенты - около 3000
Количество записей в регистре бухгалтерии 2500000

Сервера:
Сервер приложения:
Процессоры: 2 x Intel Xeon E5630
Опративна память: 32 Гб
Дисковая подситема: Два RAID 1, каждый из двух SAS дисков

Сервер СУБД:
Процессоры: 2 x Intel Xeon E5645
Опративна память: 96 Гб
Дисковая подситема: Система - RAID 1 из 2ух дисков, базы данных + логи - RAID 10 из 4ех дисков, tempdb - RAID 0 из 2ух дисков. Диски везде SAS.

Бэкапы делаются средвтвами СУБД один раз в сутки.
kuntashov; Bukaska; romansun; +3 Ответить
114. romansun 189 20.12.12 20:05 Сейчас в теме
(99)(93)

ребят, спасибо за ответы
214. pbazeliuk 22.12.12 17:19 Сейчас в теме
(99) AErzikov, Странный проект. А вот почему:
1. Для подбора серверов использовалось нагрузочные тесты? Можно же обойтись более слабыми серверами для нагрузки - 300 документов в день и 350 пользователей.
2. От чего у Вас база раздутая такая при 300 документов в день? Даже если 50% это прикрепленные файлы получается довольно много 35Гб.

Для сравнения:
у нас в месяц вводится около 100.000 документов - база всего 22ГБ и это почти за 2 года.
Количество элементов в справочниках:
Номенклатура - около 70000
Контрагенты - около 35000
Есть несколько тяжеловесных регистров с 50,000,000 и более записей.
Оперативные показатели можно получить мгновенно.
Блокировки очень нереально редкое явление, интенсивно работает от 100-150 пользователей.

Да и чем там занимались 20-32 человека не понятно. Одна мысль нам бы такие ресурсы мы б космический корабль построили.
tramontana; iov; +2 Ответить
226. tango 488 24.12.12 08:48 Сейчас в теме
(214) Baza,
нам бы такие ресурсы мы б космический корабль построили
эта мысль возникает у всех, кто представляет себе внедрение как "взял и накодил"
AlexO; barelpro; Hany; +3 Ответить
230. Hany 24.12.12 12:20 Сейчас в теме
(226) tango, да, накодить - это приблизительно 20%..тестирование прим. 60%...Если по другому - пускается сырой участок прямо в рабочую конфигурацию - и перекодинг 60%..
274. AlexO 126 17.01.13 16:24 Сейчас в теме
(226) tango,
как "взял и нашкодил"
:)
227. AErzikov 24.12.12 11:35 Сейчас в теме
(214) Baza,
1. Для подбора серверов использовалось нагрузочные тесты? Можно же обойтись более слабыми серверами для нагрузки - 300 документов в день и 350 пользователей.

Для подбора серверов не использовались нагрузочные тесты, запуск просход на том, что есть. В дальнейшем север СУБД был заменен на тот, описание которого я приводил. Решение по конфигурации серверов принимали IT специалисты заказчика. Единственное, что мы испльзовали перед запуском что бы понять возможности оборудования это был СНТ(Стандартный нагрузочный тест из состава КИПа).




2. От чего у Вас база раздутая такая при 300 документов в день? Даже если 50% это прикрепленные файлы получается довольно много 35Гб.


Это связвно с наличием довольно больших таблиц и с тем, что используется много разных видов документов.
+ Приложил табличку с данными по объемам для базы без вложеных файлов.
Прикрепленные файлы:
Размеры таблиц.xlsx
romansun; +1 Ответить
229. barelpro 985 24.12.12 12:07 Сейчас в теме
(214) Baza,
Да и чем там занимались 20-32 человека не понятно.

хоть и говорят, что 9 женщин не родит за 1 месяц, но как раз на проектной стадии "разработка" такое возможно. Другими словами за счет большого количества разработчиков удалось сильно распараллелиться и выиграть время
231. pumbaE 620 24.12.12 12:22 Сейчас в теме
(229) barelpro, как было организовано взаимодействие связанных задач при параллельном кодинге?
Были ли codereview от заказчика, анализ изменений и согласование где будут производится доработки?
Был ли у заказчика штатный программист или же приходящий для проверки?
232. romansun 189 24.12.12 12:36 Сейчас в теме
(231)

обещают отдельную статью - самое, да, вкусное :)

Меня тоже весьма интересуют организационные моменты.
233. barelpro 985 24.12.12 12:46 Сейчас в теме
(231) pumbaE, не хотелось забегать в перед, т.к. Антон Щекачев обещал эту тему раскрыть в отдельной статье. Скажу только, что после этого проекта мы приглашали к себе Agile-тренера, и мы с удивлением констатировали, что интуитивно уже давно разделяем agile-манифест и принципы Scrum
234. tango 488 24.12.12 13:01 Сейчас в теме
(233) barelpro, разделять можно сколько угодно, но засада - это
product owner — заказчик или его полномочный представитель, определяющий требования к продукту

если нет, то нет :)
**
а если есть, то такой чувак может сделать себе автоматизацию, просто раздавая задания на ИС

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

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

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

собственно, схема Белова на то и направлена, чтобы исполнителя изолировать от заказчега, а менеджеры, соответственно, об 1с только чтоб как бы слышали, что такая есть

**
в общем, для возникновения и-команды необходима прозрачность условий и согласие учаснегов
236. ASchekachev 119 24.12.12 14:40 Сейчас в теме
(231) pumbaE, все вопросы не относящиеся к функциональной части проекта мы собираем и к концу января ответим на них в рамках отдельной статьи посвященной управлению на проекте.
235. ASchekachev 119 24.12.12 14:06 Сейчас в теме
(214) Baza,

Да и чем там занимались 20-32 человека не понятно. Одна мысль нам бы такие ресурсы мы б космический корабль построили.

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

За все время в проекте приняли участие:
- 51,85% - разработчики
- 29,63% - консультанты, методологи
- 18,52% - ТРП (технические руководители проекта)
237. pbazeliuk 24.12.12 14:42 Сейчас в теме
(235) меня очень интересует как проверяли качество выполненых работ? Производительность при стремительных ростах объемов? Считали ли APDEX и как?



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



P.S. По поводу нюансов бизнеса, вот у нас очень актуально высокая скорость получения данных. Розница, крупный опт, даже задержки при поиске товара (среди 70.000) более 2 секунд это уже много. Блокировок не должно быть вовсе или очень редко. Постоянный парсинг конкурентов в режиме онлайн. Логистика с точностью выезда со склада до 5 минут и прибытия с разбросом до 1 часа.
238. tango 488 24.12.12 14:49 Сейчас в теме
(237) Baza,
задержки при поиске товара
имхо - отнюдь не есть
нюансы бизнеса


(236) бюджет проекта по-статейно представите?
239. ASchekachev 119 24.12.12 14:53 Сейчас в теме
(238) tango, не обещаем, но все возможно.
240. pbazeliuk 24.12.12 14:54 Сейчас в теме
(238) tango, а вот с этим можно поспорить, время сильно регламентировано и даже за 5 минутное отсутствие на рабочем месте - нужно указать причину этого самого отсутствия. За такие нормы у нас и зарплата на 40-200% выше чем в среднем в регионе.
241. ASchekachev 119 24.12.12 14:57 Сейчас в теме
(237) Baza, о качестве работ в статье по управлению напишем.

Производительность при стремительных ростах объемов? Считали ли APDEX и как?

Об этом напишет Андрей Ерзиков, он все эти вопросы решал с Фирмой 1С в рамках ЦКТП.
245. AErzikov 25.12.12 17:50 Сейчас в теме
(237) Baza,
Производительность при стремительных ростах объемов? Считали ли APDEX и как?

Некоторое проблемы с производительностью были, они решались в рамках проекта ЦКТП совместно с фирмой 1С.
Они были в основном связаны с тем, что многие документы при доработках обросли дополнитлельными достаточно тяжелыми алгоритмами, и соответственно проводились достаточно долго. Проблем с блокировками не было. Самы тяжелой операцией было проведение ОПЗС, т.к. при проведении производится полное разузлование для заполнение табличной части "Распределение материалов", а так же при проведении ОПЗС автоматически формируется требование накладная для списания матеиалов. Основным выходом для ускорения проведения было писать часть движений ОПЗС (РАУЗ + Бух регистры) фоновым заданием.
APDEX считали встрайвая в нужные места замеры времени.
Для замеров времени использовали соответствующие куски из БСП.
116. MiklBreg 21.12.12 09:51 Сейчас в теме
(11) romansun,
Внедрялся ли какой-то поцеховой оперативный учет


Краткое описание действующей схемы:

1. Пользователь инициирует заполнение "Плана производства по дням недели" данными о недельном объеме выпуска (из регистра "Планы производства" по подтвержденным документам). Самостоятельно распределяет количество между днями недели. При необходимости меняет тех.карту (участок) и/или спецификацию.

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

3. Под потребности заказов на производство формируются заявки на перемещение материалов с центрального склада на склады производственных площадок (участков) - документы "Внутренний заказ". На основании которых затем выполняются собственно перемещения.

4. Остатки заказов на производство выводятся в печатную форму в виде заданий на участки.

5. По итогам дня каждым участком вводится "Отчет производства за смену". Используется обработка заполнения табличной части с формой в виде таблицы остатков по заказам на производство данного участка. Для фактически изготовленных позиций пользователь в отдельной колонке этой таблицы указывает выпущенный объем.

Текущее состояние производственной программы просматривается универсальным отчетом по регистру заказы на производство (строки: участки, номенклатура; колонки: даты выпуска).
118. tango 488 21.12.12 10:22 Сейчас в теме
(116) MiklBreg, не возникала ли необходимость в таком функционале:

материал передан в цех (то бишь в производство, д20-к10) и постепенно переносится на продукцию
но перенос занимает достаточно долгое время, при этом продукция не выпускается, но может возникнуть желание знать, сколько материала еще лежит в кладовке цеха, а сколько уже реально вложено в единицу изделия (эта единица еще не изготовлена)
120. ASchekachev 119 21.12.12 12:53 Сейчас в теме
(118) tango, в дополнение (119). В номенклатуре на закладке "Настройка учета" есть флажок "Вести оперативный учет остатков незавершенного производства", им можно контролировать остаток в НЗП. Но этим флажком лучше не злоупотреблять и устанавливать его только у той номенклатуры по которой действительно важно понимать текущий остаток в НЗП. К примеру, очень дорогие материалы, очень редки и т.д.
122. iov 364 21.12.12 13:05 Сейчас в теме
(118) а еще бывает такое что этот материал уже попал в полуфабрикат который не передан на склад (промежуточное производство например) и материала нет на складе и иногда не выяснить на что он потрачен (нет выпуска).
Мы использовали виртуальные склады передачи в конце смены (сдал работу/наработку/полуфабрикат/недоделку - принял) Но это уже учет на поставленном производстве. На "диких" производствах только жесткий контроль (внос -вынос материалов - продукции).
259. Рамзес 26 06.01.13 11:34 Сейчас в теме
(122) iov, зачем использовать виртуальные склады? Можно же делать выпуск с направлением выпуска "на затраты"?
263. iov 364 06.01.13 13:01 Сейчас в теме
(259)Не всегда и не все уходило в итоге на затраты. Да и передачи в конце смены позволяли контролировать ... А выпуск на затраты полуфабрикатов?
264. Рамзес 26 08.01.13 11:58 Сейчас в теме
(263) iov, выпуск полуфабрикатов как раз удобно делать с направлением выпуска "на затраты". А если для каждого промежуточного состояния продукции нецелесообразно создавать полуфабрикат в справочнике "Номенклатура", то нужно использовать вид выпуска "наработка".
242. ASchekachev 119 25.12.12 16:25 Сейчас в теме
В дополнение к ответу (116) на вопросы (11). Прилагаю схему того, что было реализовано по производству в УПП.
Прикрепленные файлы:
243. tango 488 25.12.12 17:38 Сейчас в теме
(242) в схеме нет снабжения вообще: ни заказов покупателей, ни даже складских запасов
**
отклонения на производстве - тоже со снабженцами связано
244. ASchekachev 119 25.12.12 17:46 Сейчас в теме
(243) tango, все верно - это схема оперативного производства без связки со снабжением. В схеме только определение потребностей материалов и получение их через внутренние заказы из кладовых.
247. mymyka 26.12.12 16:14 Сейчас в теме
(243)Фирма, которая может убить 1-2 миллиона евро на автоматизацию может себе позволить морозить оборотные средства в страховых запасах материалов. В таких условиях снабжение может работать подходами - с утра сформировали потребности, заказали, успокоились до следующего дня. Совершенно бессмысленно активно включать их в бизнес-процесс как отделбную веху, отчетиком по потребностям на скд обойдутся )
248. tango 488 26.12.12 16:20 Сейчас в теме
(247) mymyka, на заменах однако без их согласования может не взлететь

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

и оценку замороженного (хоть и не наша, 1снегов, пичалька) провести таки следует - валюта автоматизации тут ни при чем
и ведь сували же им этот ексельный файлик. только сказать не смогли, чего хотели. а БиТ культурненько промолчал
251. ASchekachev 119 27.12.12 17:49 Сейчас в теме
(247) mymyka,

Фирма, которая может убить 1-2 миллиона евро на автоматизацию может себе позволить морозить оборотные средства в страховых запасах материалов

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

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

Эффект ухода от экселевских файлов в первую очередь позволил всем работать в едином пространстве и оперативно получать информацию. Новым заинтересованным в информации сотрудникам достаточно взять инструкцию и им не нужно искать владельцев файлов эксель.
Сам организационный процесс при внедрении изменен не был.
260. Рамзес 26 06.01.13 11:50 Сейчас в теме
(242) как я понимаю функционал посменного планирования не используется. По какой причине?
266. ASchekachev 119 10.01.13 12:29 Сейчас в теме
(260) Рамзес, да функционал посменного планирования не использовали.
Заказчик привлекал бизнес-тренера для проработки модели MRP II. Предложенная схема, учитывающая бизнес и потребности Заказчика не сочеталась с типовыми инструментами посменного планирования. Поэтому было принято решение не дорабатывать существующую модель, а разработать полностью новые механизмы.
261. Рамзес 26 06.01.13 11:55 Сейчас в теме
(242) заказчик не ставил задачу использования маршрутных листов (сопроводительных карт, которые сопровождают партию продукции от момента запуска до выпуска)? Не приходилось ли вам сталкиваться с такой задачей и если да, то как вы ее решали?
268. ASchekachev 119 10.01.13 12:38 Сейчас в теме
(261) Рамзес, на Ваш вопрос ответит Михаил Брегадзе, он был ТРП по блоку оперативное производство.
270. MiklBreg 12.01.13 05:37 Сейчас в теме
(261)
(242) заказчик не ставил задачу использования маршрутных листов (сопроводительных карт, которые сопровождают партию продукции от момента запуска до выпуска)? Не приходилось ли вам сталкиваться с такой задачей и если да, то как вы ее решали?

В случае, когда продукция с какого-то уровня передела приобретает какие-либо уникальные признаки, сохраняющиеся до конечного выпуска, можно порекомендовать в качестве входов и выходов спецификаций использовать одну номенклатуру с характеристиками, одним из свойств которых будет "стадия обработки". В некоторых конфигурациях (например, от ИТРП) такая сущность выделена в отельный (самостоятельный) разрез аналитики - "заход" - в учетных регистрах и НСИ (Спецификациях, Техкартах).
Для документального сопровождения такого технологического процесса можно предложить некий "чек-лист" с отметками о выполнении очередной тех.операции (на партию или, как частный случай, единицу продукции). При желании (необходимости) можно реализовать его электронный вариант в базе (штрих-код партии, операции, исполнителя, плюс дата, время и т.п.).
На предприятиях наверняка существуют свои формы такого рода сопроводительных документов (маршрутные листы и т.п.) и при необходимости "нарисовать" их в базе не проблема.
Возможны, конечно, различные нюансы формирования именно текущего варианта маршрута при решении задач оптимизации загрузки оборудования и т.п. Но это уже другая история...
272. Рамзес 26 17.01.13 13:08 Сейчас в теме
(270) MiklBreg,
При желании (необходимости) можно реализовать его электронный вариант в базе

Именно этот момент мне интересен. Лично я попытался сделать так. При запуске партии в производство создается серия номенклатуры. Эта серия завязана на позицию в заказе на производство. Электронный вариант маршрутной карты это отчет, собирающий в себе информацию об этой партии: нормативный материал, фактически выданный материал, технологические операции, какие комплектующие должны быть поданы на технологическую операцию, в какие сборочные единицы войдут детали из данной партии и т.д. Такой подход имеет ряд минусов. Какой вариант выбрали вы? Создавали в конфигурации новый Документ "Маршрутная карта"?
273. MiklBreg 17.01.13 16:19 Сейчас в теме
(272) Рамзес,
увы, на практике до реализации решения таких задач не доходило. Соответственно, никакой вариант выбирать не приходилось. Как правило, в каждой конкретной ситуации оказывается свой более оптимальный вариант решения (с учетом действующих допущений, ограничений и т.п.).
117. MiklBreg 21.12.12 10:09 Сейчас в теме
(11) romansun,
Расчеты загрузки цехов?


При формировании заказов на производство (как продукции, так и полуфабрикатов) никакой контроль ограничений производственных мощностей не осуществляется.
Есть возможность использовать добавленные специализированные отчеты "Проверка достаточности рабочих центров" и "... персонала".
Потребности времени работы рабочих центров и персонала на даты рассчитываются по технологическим картам и заказам на производство. В технологическую карту добавлены реквизиты по трудоемкости.
Доступное на эти даты время использования ресурсов определяется по графикам работы рабочих центров и добавленному регистру сведений (численность персонала и количество часов рабочей недели для каждого участка).
При выявлении превышений потребностей времени ресурсов над их доступностью либо корректируется план производства по дням недели (уменьшается), либо увеличивается доступность (вводятся сверхурочные часы или дополнительный персонал).
12. milkers 2290 19.12.12 23:15 Сейчас в теме
Что происходит при необходимости обновления бухгалтерского, зарплатного блока до следующей версии?
Почему нельзя было разделить на две базы управленческую (переписанную вдоль и поперек) и регламентную,в качестве которой использовать стандартную УПП? Объем работ упал бы в разы.
96. ASchekachev 119 20.12.12 17:24 Сейчас в теме
(12) milkers,
Что происходит при необходимости обновления бухгалтерского, зарплатного блока до следующей версии?

Полноценное обновление ставим только перед сдачей отчетности. Не чаще чем раз в квартал иногда пол года.
Зарплата в этой базе не ведется, для этих целей используется отдельная база на конфигурации ЗиУП.
Почему нельзя было разделить на две базы управленческую (переписанную вдоль и поперек) и регламентную,в качестве которой использовать стандартную УПП? Объем работ упал бы в разы.

Потому что задача была работать всем в единой базе, управленцы ежедневно формируют оперативную отчетность по упр. учету, изменяют аналитику упр. учета (статьи оборотов, счета учета УУ и прочую инф.). При такой активной работе с упр. частью обмен между базами тормозил бы процесс и накладывал определенные функции по контролю этого процесса. Обновление здесь лучше, чем мониторинг обменов и задержка в информации.
Если бы можно было решить вопрос внедрением двух баз, то мы только ЗА. Нам знаете тоже, чем проще, тем лучше.
14. serega_sun 20.12.12 05:08 Сейчас в теме
Жду статью по управлению проектом. Было бы интересно.
15. ASchekachev 119 20.12.12 08:54 Сейчас в теме
Alraune, bagaev, tango, romansun, milkers, serega_sun спасибо за участие и Ваши вопросы.

Я и мои коллеги с проекта обязательно ответим на все поступившие и поступающие вопросы, может не так оперативно как хотелось (текущая работа).

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

romansun, serega_sun, про управление текущим проектом и организацию процесс обязательно напишу отдельную статью в середине января 2013.

Сегодня планирую отвечать на вопросы примерно с 15:00.
16. АлексейН 2 20.12.12 08:59 Сейчас в теме
Интересное внедрение программы.
По поводу "адского труда" согласен на все 100%.
17. comol 3913 20.12.12 09:38 Сейчас в теме
1) Из описания совсем не понятно чем могли 20 человек год заниматься :). Можно было бу уже всё УПП на УФ переписать :). Самое интересное что можно рассказать о проекте как раз ИХМО в этом.

2) а в чём "МЕГА" для проекта? 300 док-тов в день это весьма средненький проект... Сколько одновременно работающих пользователей, сколько блоков и т.п....
20. tango 488 20.12.12 10:15 Сейчас в теме
(17) comol,
Можно было бу уже всё УПП на УФ


вообще в (8) ответили как бы

**
300 док-тов в день

281 заказ в день
**
(0):
В базе одновременно работает около 650 пользователей. Около 300 внутренних, остальные ключевые клиенты.
Прикрепленные файлы:
35. comol 3913 20.12.12 11:37 Сейчас в теме
(20) tango, Ага... спс... такое чувство что просто клиентов пустили заказы самостоятельно бить :). а 300 юзеров - вполне средняя компания...
36. tango 488 20.12.12 11:39 Сейчас в теме
(35) comol, для московской мамы - неплохая цифра
другой вопрос - чем они там занимаются ?!? (эх, АлексО нам бы рассказал :))
98. ASchekachev 119 20.12.12 17:37 Сейчас в теме
(17) comol,

1) Из описания совсем не понятно чем могли 20 человек год заниматься :). Можно было бу уже всё УПП на УФ переписать :). Самое интересное что можно рассказать о проекте как раз ИХМО в этом.

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

2) а в чём "МЕГА" для проекта? 300 док-тов в день это весьма средненький проект... Сколько одновременно работающих пользователей, сколько блоков и т.п....

Уникальность этого проекта в его очень разнообразной функциональности, ведением всего учета в одной базе, большом количестве пользователей и в очень сжатых срока проекта от момента старта проекта (конец мая 2011) до начала работы всех пользователей в новой базе с полным отказом от старых систем (10 января 2012). После 10 января это уже была промышленная эксплуатация и сопровождение.

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

Описание того, что сделано http://делаемпроекты.рф/project/6/
Пресс релиз по проекту http://v8.1c.ru/news/newsAbout.jsp?id=8273
102. comol 3913 20.12.12 17:50 Сейчас в теме
(98)
Согласен, что за год разработки можно было переписать много, но реально в годовом проекте разработка занимает даже не половину.

Так вот и написали бы, как проектировали, какие подходы использовали, как коллективную работу организовали, какие модели строили, насколько получилось спроектировать в соответствии и т.п. ИХМО было бы куда интереснее чем описание проведенных доработок, которые, как отметил Артур (28) несут достаточно мало полезной информации.
Другое дело что подходами к проектированию и организации работ не каждый наверное готов делиться... :)
103. tango 488 20.12.12 17:51 Сейчас в теме
(102) comol, ага, и еще исполнение бюджета по-статейно :)
18. comol 3913 20.12.12 09:40 Сейчас в теме
Если заказчик согласует ещё очень хотелось бы модель БП посмотреть...
21. tango 488 20.12.12 10:19 Сейчас в теме
(18) comol, а чё БП? с ТЗР потёрлись, агентские услуги подпилили, и от РАУЗа в шоке, а так БП как БП :)
19. Sybr 233 20.12.12 10:01 Сейчас в теме
На сколько я знаю у Световых технологий несколько заводов в разных городах, сейчас они все работают в единой базе? Или внедрение было только на московском предприятии?
22. tango 488 20.12.12 10:22 Сейчас в теме
(19) Sybr,
налажен оперативный обмен данными между всеми подразделениями и филиалами компании «Световые технологии» в России
100. ASchekachev 119 20.12.12 17:46 Сейчас в теме
(19) Sybr,

На сколько я знаю у Световых технологий несколько заводов в разных городах, сейчас они все работают в единой базе? Или внедрение было только на московском предприятии?


У Световых технологий в России завод один в Рязани. Автоматизация проходила на двух площадках Москва (Торговая компания) и Рязань (Производство). Все они работают в единой базе.
http://www.ltcompany.com/page.php?id=7 - тут можно подробнее прочитать историю развития данной компании.

С января 2013 года запуск завода в Украине (старт работ был в июле 2012) на УПП для Украины, аналогичный проект России, только уже много чего взяли с России, сильные изменения только в их регл. учете.
24. Oleg_nsk 153 20.12.12 10:56 Сейчас в теме
В настоящее время мы заканчиваем полугодовой проект по внедрению УПП + БитФинанс на предприятии, которое оказывает услуги металлообработки. От РАУЗа отказались поскольку опасаемся набивания некорректных данных людьми с невысокой квалификацией. Скажите, возникали ли у вас какие-нибудь проблемы после внедрения, связанные с человеческим фактором? Или мы зря РАУЗа боимся?
25. mymyka 20.12.12 11:00 Сейчас в теме
(24)Напротив, РАУЗ куда устойчивее к человеческому фактору, зря вы его боитесь.
26. Oleg_nsk 153 20.12.12 11:09 Сейчас в теме
(25) mymyka, А можете порекомендовать хорошую литературу или статью или видеокурсы и т.п. по РАУЗу?
29. ASchekachev 119 20.12.12 11:19 Сейчас в теме
(26) Oleg_nsk, на текущий момент (то что знаю я) есть:
1. Курсы у Фарита Насипова - http://www.nasf.ru/
2. Книжка от 1С - Е.Абрашина, И.Емельянов "Использование механизма расширенной аналитики в "1С:Управление производственным предприятием"
Oleg_nsk; +1 Ответить
30. tango 488 20.12.12 11:20 Сейчас в теме
32. mymyka 20.12.12 11:22 Сейчас в теме
(26)Да нет особо литературы по РАУЗу, в принципе он прозрачен и прост, один раз настроить способы распределения затрат и все. Для этого и желтых книжек достаточно, плюс есть немного инфы у Гилева и Насипова на сайте.
34. tango 488 20.12.12 11:29 Сейчас в теме
(32) mymyka, он прозрачен и прост с т.з. программера 1сь
(пока он не увидел запросы :) )
а юзер не может с карандашиком/счетами/екселем повторить расчет, вот и дергается, поскольку приходится верить программе, не имея возможности ее проверить

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

где-то тут по соседству мелькнула мысль о несовместимости РАУЗа с МСФО - кто-нибудь может развернуть тезис?
37. mymyka 20.12.12 11:40 Сейчас в теме
(34)говоря прозрачен и прост, я имел ввиду, естественно, анализ "незакрывающегося" месяца, а не алгоритм расчета )насчет МСФО хз, но главный минус РАУЗА - несовместимость с директ-костингом, многие руководители хотят видеть текущее состояние дел, а не итоги в конце месяца )
39. tango 488 20.12.12 11:42 Сейчас в теме
(37) mymyka,
РАУЗА - несовместимость с директ-костингом
ага, об этом я все время упускаю почему-то :(
40. AShley 20.12.12 11:43 Сейчас в теме
(37) mymyka, Можно же пустить расчет себестоимости с некоторой переодичностью - раз в 2 часа например. фононовым заданием. А вот отчет по Валовой прибыли многих не устраивает, особенно если учитывать нужно по ФИФО.
Оставьте свое сообщение