Обмены данными в 1С

С обменами данных мы сталкиваемся постоянно, фактически в любом приложении на компьютере хранятся некие данные. Поскольку они уже хранятся всегда существует соблазн их использовать и использовать без дополнительных усилий. Для этого было выработано множество путей. Обмены можно поделить на файловые (обмениваемые данные хранятся в виде файлов — не важно каких (текстовые, csv — данные с разделителями, dbf, xml, json, электронные таблицы Excel и OpenOffice, Access и проч), которые обрабатываются специальными механизмами 1С, так и передача данных напрямую в систему управления базой данных (СУБД, например Microsoft SQL, IBM DB2 или PostgreSQL) или посредством COM, OLE подключений к базе данных или посредством Web- или HTTP-сервисов, а также посредством REST интерфейса (протокол OData 3.0, который как раз работает посредством протокола http) .

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

«Правильные» подходы к внедрению программных продуктов

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

Вообще существует множество подходов к организации ПРОЕКТА внедрения программного продукта.  Именно ПРОЕКТА. Существует множество методологий работы с проектами: Водопад, PMBoK, Agile и еще множество страшных слов… Но сводятся все они в конечном счете к циклу Деминга — Шухарта — PDCA.

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

Причин для этого может быть несколько. Основные:

  • Отсутствие на предприятии группы специалистов, ответственной за внедрение. На предприятии должна быть КРИТИЧЕСКАЯ масса высокопоставленных специалистов, понимающих куда нужно двигаться и каким образом достигать намеченных целей. И важно, чтобы эти цели формулировало высшее руководство.
  • Низкая вовлеченность будущих пользователей программного продукта в процесс внедрения, непонимание целей внедрения, собственных задач, недостаточная мотивация на обучение, низкий уровень знаний и отсутствие контроля руководства над деятельностью.
  • Попытка подстроить программный продукт под существующие методы работы (лоскутную автоматизацию) вместо проработки и оптимизации существующих бизнес процессов в единый механизм (попытка «натянуть сову на глобус»). Неадекватное использование чужих наработок для своего бизнеса. Последним очень грешат франчайзи, предлагая решения, вполне удачные для одного предприятия и совершенно неприспособленные для другого.
  • Боязнь получения результата. Возможны ситуации, когда высшее руководство или заместители декларируют некие цели, например повышение прозрачности использования денежных средств, а на самом деле решения этой задачи по разным причинам пытаются не допустить. В качестве примера могу привести опыт работы зама директора по ИТ на одном из предприятий приборосторения около 14 лет назад. Ставилась задача создать единую систему от технического задания на входе до программ на станки ЧПУ на выходе. Короче связка CAD-CAM-CAE-PLM-ERP2. Было своими силами произведено обследование предприятия, оцифрованы бизнес процессы, схематизированы (IDEF), составлен альбом документов, используемых на предприятии с образцами заполнения. Был найден подрядчик и (бесплатно!) проработан контрольный пример на 5 изделиях. Причем во всех случаях общения с исполнителями достаточно было использовать результаты обследования. При обследовании было выявлено множество никому не нужных функций, ошибок учета и прочих досадных мелочей. Через некоторое время контрольный пример был продемонстрирован высшему руководству и среднему управленческому звену. Если среднее звено было готово включаться в работу фактически сразу, то с высшим руководством вышла заминка. Генеральный сказал, что если договор согласовывают замы, то все это запускаем в работу, финансовый директор поинтересовалась, можно ли это приобрести дешевле… Но технический директор в приватной беседе сказал, что до меня работали и после меня будут работать также как и сейчас и все эти новшества никому нафик не нужны. Коммерческий сказал, что в данный момент для системы нет объективных данных. И на этом все заглохло. Команда внедрения была деморализована и мы расползлись кто куда… А жаль. Как выяснилось позже у всех руководителей были свои «бубновые» интересы.
  • Недостаточно верное определение проблемных зон и соответственно неверное определение способов воздействия. Встречал организацию, где проблемы были в производстве и проблемы технического характера, а напрягалась руководством бухгалтерия, чтобы опосредованно выявить причины нестабильной работы производства. Как в анекдоте: «…А где ты потерял часы — Там — А чего же ищешь здесь — А здесь светлее».
  • Программный продукт куплен «потому что все покупают и устанавливают» или по настоятельной рекомендации знакомого франчайзи.
  • Имеются попытки сэкономить на специалистах или оборудовании. Понятно, что специалист стоимостью условно 120 тыс.рублей, сможет какое то время проработать условно на 60 тыс. рублей, но недолго, месяц — два. И все. И два специалиста по 60 тыс. рублей чаще всего не могут заменить одного за 120. И оборудование, уникальное для 2010 годов отказывается нормально работать в 2021 году. Даже если оно полностью исправно.

Вот это основные случаи, когда проект внедрения обречен. Спасти проект в данном случае может только «упертость» руководителя проекта, граничащая с фанатизмом.

Но адепты Agile Scrum скажут, что благодаря системному подходу, все вышеуказанные проблемы будут периодически всплывать и команда их решит. Но, для этого должна иметься КОМАНДА КВАЛИФИЦИРОВАННЫХ СПЕЦИАЛИСТОВ и в методике SCRUM и в предметных областях. Вопрос только в том, где их взять и сколько они стоят. Если они «внешние», то они будут пытаться в первую очередь решить СВОИ проблемы, а не проблемы предприятия, если они внутренние — то вопрос где их взять, как содержать и мотивировать. Про KPI поговорим в следующий раз, поскольку мотивация посредством может …хи-хи… работать во вред предприятию. Следует также заметить, что наличие сертификатов у специалиста, ответственного за внедрение, не означает успешности внедрения, это говорит о том, что он знает и умеет применять инструментарий продукта, а сумеет ли он переломить сопротивление пользователей — другой вопрос.

Начало внедрения программного продукта

Барон фон Гринвальдус,
Сей доблестный рыцарь,
Все в той же позицьи
На камне сидит.

Козьма Прутков

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

  1. Организационно-правовую форму автоматизируемого предприятия (ООО, АО, ИП, КФХ, ПАО и проч.) , систему налогообложения автоматизируемой организации (общая, упрощенная, патентная, налог на профессиональный доход и единый сельскохозяйственный налог). Желательно подготовить папочку с документами (копиями) различных выписок, уставов и прочих документов, используемых при регистрации организации. Они пригодятся дальше. В современных версиях продуктов фирмы 1С есть возможность заполнять реквизиты по ИНН организации.
  2. Формулируем основную проблему(ы) текущего состояния учета, инвентаризируем имеющиеся программные продукты, компьютеры, офисное оборудование. Для программных продуктов желательно указать текущую версию, условия приобретения. Для компьютера — операционную систему, ее разрядность, тип центрального процессора и его рабочую частоту, объем оперативной памяти и объем памяти жесткого диска. Эти параметры можно найти в компьютере — Панель управления\Все элементы панели управления\Система. Для офисного оборудования нужно указать значимые параметры, в том числе порты подключения, например COM или USB. Есть ли какие то данные для первоначального ввода в систему, в каком виде (бумажный, сканы первичных документов, таблицы Excel/OpenOffice и проч.)
  3. Оргструктуру организации (иерархию подразделений, при наличии)
  4. Виды деятельности организации (или коды ОКВЭД из регистрационных документов)
  5. Есть ли внешнеэкономическая деятельность / работа с валютой у организации
  6. Склады, магазины с указанием типа (оптовый/розничный/производственный), степень автоматизации и ее перспективы в ближайшем будущем.
  7. Общее количество сотрудников, количество сотрудников, которые будут работать в системе, их функционал, уровень прав, запрещенные действия (например правка документов «задним числом», превышение остатка товаров на складе при оформлении документов)
  8. Есть ли менеджеры по закупкам/продажам, нужно ли фиксировать их деятельность документально и насколько детально. Есть ли «мобильные» менеджеры. Оформляются ли заказы, счета, коммерческие предложения. Кем
  9. Есть ли у клиентов особые требования к печатным формам первичных документов, какие
  10. Сколько предполагается видов цен, есть ли скидки/наценки, нужно ли их отражать в печатной форме первичных документов.
  11. Требования к наличию регламентированного и/или управленческого учета. Регламентированный (он же бухгалтерский и налоговый) учет предназначается для сдачи регламентированной отчетности и определения сумм оплачиваемых налогов, взаиморасчетов с клиентами, управленческий характеризует движение товарных и денежных ресурсов организации в любой момент времени. Это разные виды учета. Есть еще учет в международной системе финансовой отчетности. Если требуется — укажите
  12. Есть ли работа с комиссионным товаром, в каком виде
  13. Есть ли собственное производство, его характер, учет незавершенного производства, комплектация/разукомплектация товаров, сложность производственных операций(есть ли , маршрутные карты, спецификации
  14. Есть ли работа с давальческим сырьем
  15. Есть ли дополнительные требования к интеграции с системами EDO, B2B, B2C, интернет магазинами, банковскими клиентами
  16. Требуется ли бюджетирование
  17. Требуется ли финансовый учет по статьям движения денежных средств
  18. Требуется ли вести кадровый учет, проводить расчет заработной платы. Какие варианты расчета заработной платы применяются.
  19. Предполагаемые варианты автоматизации в ближайшее время, через год, через три.
  20. Прочие моменты на которые следует обратить особое внимание при внедрении

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