«Бороздить космические просторы Вселенной» мы все – горазды, но, возьмем задачу попроще, тем более, что вы претендуете на универсальность. Средняя производственная фирма, порядка 1000 человек сотрудников. Главная проблема – учет заработной платы и учет ресурсов, поскольку типовые конфигурации не давали нужного функционала. Основные требования – внешняя отчетность, с которыми типовые конфы не слишком дружили. Другая проблема – неудобство работы в типовых конфигурациях, поскольку они всегда делались и делаются по принципу: «Нам с ними не работать!» и «Наши конфы не поддерживают ваши бизнес-процессы? Меняйте свои бизнес процессы! Ради вас мы типовые конфигурации переделывать не будем!». Третья проблема – преемственность и стоимость проектов внедрения и сопровождения. Особенно, если фирма не готова платить заметные деньги на автоматизацию собственного учета, просто потому, что их у неё нет. А преемственность потребовалась при переходе от украинского учета к учету по законодательству ЛНР, а затем и РФ (самая жестокая боль – смена Плана Счетов на ходу).

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

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

С таким подходом, я бы далеко не уехал.

У фирмы «1С» самое главное достижение – это платформа «1С77», реально, система быстрой разработки, аналогов которой не существует. Благодаря ей, мой первый рабочий прототип учета заработной платы «взлетел» уже через три месяца. Да, потом я его еще, около двух лет, шлифовал, с утра до вечера, но при этом система постоянно работала на реальном производстве, все шероховатости и претензии я быстро устранял.

Затем я разработал и внедрил учет ресурсов. Единственное, что более-менее работало в наших условиях – это «ПУБ (Производство, Услуги и Бухгалтерия) для Украины», которую я затем адаптировал для «ПУБ для ЛНР,» а затем постепенно интегрировал в «ПУБ для РФ».

«Зарплата» у меня всегда была автономной, а оперативный учет новая главбухша перевнедрила с моего «Учета Ресурсов», на «ПУБ для Украины», что заметно отразилось на удобстве учета. Как она говорила: «В ПУБ я играть умею, а в твой Учет Ресурсов – нет!». А вот «зарплату», при всем своём желании и моей искренней помощи (я ей нашел в Интернете порядка десяти программ, включай ЗУП) она перевнедрить не смогла. Ибо наши бизнес процессы не соответствовали типовым.

Что я могу сказать по методологии учета в типовых? На мой взгляд, она не оптимальна. Фирма «1С» стремиться не к легкости, простоте и красоте, а к банальному зарабатыванию «бабосов».А разве на простой и понятной программе заработаешь лишние монгольские тугрики?

Не оптимальны не только типовые конфигурации, но и сама платформа «1С». Сколько я себя помню, всегда хотел создать собственный вариант а-ля «1С77», вроде «2С» (этот опенсорсный проект реально существует, написан на C++ / MFC, как и оригинальная платформа, но развития не получил, да и концепция там была реализована так себе). Может быть, с использованием «Искусственного Идиота», когда-нибудь вернуть к этой идее.

Про «восьмерку» («1С8х») и говорить не приходится. Её девиз: «всё усложняем, усложняем и еще раз усложняем!», чтобы в итоге родить монстров типа: «1С:ERP» и «1С:MES». Да, на «восьмерке» можно неплохо зарабатывать в силу её сложности, поэтому, если бы я начинал свою карьеру сейчас, заново, то выбрал бы её.

Но, скорее всего, пошел бы по такому пути:

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

• Весь реальный внутренний учет ведём не в «Экселе», а в «1С77», в 100%-но собственной конфигурации.

• В официальную «1С8х» экспортируем свои данные из «1С77», с помощью собственной обработки «КД» («Конвертация Данных»), поддерживающей и обратный импорт.

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

Я начал было идти по этому пути, но нашу фирму (после перехода под юрисдикцию РФ) приобрёл новый собственник, а у него оказались свои представления о «прекрасном», поэтому, фирму он ликвидировал. Ибо, «капитализьм», блин. А в социализм мы вернемся еще не скоро (лет через десять, не раньше).

Так что чужая система это хорошо, но если она сильно жесткая, сложная и малоудобная, то лучше поискать более дешевые и комфортные альтернативы, хотя бы рамках продуктов фирмы «1С».

Так что Мюллер был прав: «Верить никому – нельзя! …» :)

levonmusoyan 30 авг в 11:06

В разборах неудачных внедрений почти всегда всплывает слой, которого нет среди пяти артефактов: состояние справочников.

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

Вопрос по вашей методологии: где в ней живет качество НСИ и есть ли у него свои критерии готовности, или это остается вне контура модели?

dull_pm 30 авг в 11:13

Спасибо за вопрос. Безусловно - актуальность и оптимизация фактических справочников вопрос максимально важный и дубликаты и неаккуратное ведение НСИ могут поломать даже идеальную модель. Если говорить о прикладном использовании Методологии, то мы храним "Статические справочники" (структура предприятия, виды номенклатуры) непосредственно в "Объектах метаданных системы" и обеспечиваем явное согласование их заказчиком до старта ОПЭ. То есть в принципе в этом смысле данные НСИ являются часть Методологии. Динамические справочники (номенклатура, контрагенты) в этом контексте остаются за рамками методологии.

levonmusoyan 30 авг в 12:40

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

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

У вас в проектах такие проверки кто-то делает до старта ОПЭ, или это всегда всплывает уже в опытной эксплуатации?

dull_pm 31 авг в 04:39

Для всех переносимых справочников и документов начальных остатков создается специализированный дополнительный документ "Загрузка начальных данных", в котором можно контролировать фактическую приемку от заказчика итоговых списков справочников и документов. При этом есть возможность использовать разные шаблоны загрузки. Например, Справочник Контрагенты имеет несколько шаблонов "Клиенты, поставщики, прочие", которые обуславливают заполнение разного набора реквизитов. Плюс каждая "порция" загружается по своему плану, так как к началу ОПЭ как правило готовы только остатки ТМЦ на складах и взаиморасчеты. В прошлой статье я раскрыл имя программы erp-tools, в you-tube есть кое-что про загрузку начальных данных этой методологией. Я полностью исключил использование программистов и КД из процесса, заменив их программным роботом и аналитики как раз эти реестры справочников и их шаблонов и ведут.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий