Мой опыт: Внедрение ERP системы

25.02.19

Бизнес-анализ

Здравствуйте, уважаемые. Хотел здесь поделиться своим опытом внедрения, и выводами, к которым пришел.  А именно, акцентировать внимание на совершенных мной ошибках. Возможно, этот опыт будет полезен тем, кому предстоит что-то где-то внедрять. Особенно, если это большой проект.

Итак, начнем.

Задача:

Суть задачи сводилась к следующему: есть программный продукт, написанный на С#. Нужно написать что-то подобное на 1С. С последующим переводом компании на новые рельсы. Сразу скажу, что фирма занимается логистикой практически по всему миру. Исполнитель один.

Я созвонился с работодателем. Меня заинтересовала эта задача, показалась очень интересной. Я приехал на собеседование, где и совершил свою первую ошибку.

Дело было так: Сижу я в кабинете. Директор рассказывает мне о своих планах, задачах. О структуре программы на С#. Всё это делается в общих фразах и с краткими образными рисунками на бумаге. Это  мое первое собеседование на фирме. Директор хочет понять, подхожу ли я ему, и задает вроде бы обычный вопрос о том, за какие сроки я бы справился с этой работой.

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

Как показала дальнейшая работа в организации, эти мои слова были ошибкой. Дело в том, что нельзя называть никаких сроков, даже примерных, пока ты точно не поймешь, с чем столкнулся. Вышло так что через 2 месяца программа не была готова. И не через 4. И даже через 6. Проект оказался достаточно сложным. Специфика организации состояла в работе с файлами. Их подгрузке и хранении в 1С….в общем не буду описывать всех моментов, добавлю только, что:

1)Директор хотел чтоб было как в старой программе. (а 1с это не С#)

2)Выгрузка данных из старой программы в новую 1С.

3)Синхронизация обмена документами и банком с бухгалтерией.

Конечно, эту работу невозможно было реализовать ни за 2 месяца, ни за 6.

Я честно трудился, а директор косился на меня и злился. Он считал, что я давно должен был сдать ему проект. Иногда сложно объяснить людям все сложности твоей работы.

Из 1й ошибки вытекала и 2я. Мы не писали ТЗ. Все понимают, что обычно сам программист себе и пишет ТЗ. Сам его и выполняет. Решено было обойтись без этой лишней волокиты и сократить сроки работы. Вышло как всегда наоборот. Только большой опыт спас меня от того чтобы не рухнуть в рутине мелких задач которые были описаны даже не для меня а другим программистам, делавшим ещё С#. Часть задач забывалась, часть была не ясна до конца.

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

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

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

Еще важное замечание. Никогда не сажайте людей на новую систему без обучения! Особенно если эти люди не знают 1С. Т.е. представьте, люди не только не знакомы с вашей системой, они и саму платформу-то не видели. Т.е. да, многие пользователи 1Са в этом смысле тупят, но эти то ребята так и вовсе! Да да, у нас вышло именно так. И это была 4я моя ошибка.

Получилось всё вот как:  Директор сказал «хм, твоя программа почти такая-же, как и та в которой они работали до этого. Им и переучиваться нечему особо.»  - Мне сложно было с ним спорить. Но по факту потом обучал я каждого индивидуально. Трудоёмкая работка.

После всего пережитого «создания ИБ» был ее запуск. Как обычно час X откладывался несколько раз. Но вскоре пришло осознание того что больше откладывать нельзя. И мы решили запускаться. Мне дали аж 3х человек на тестирование проекта. Сразу скажу, все они оказались жутко занятыми людьми и очень мало времени посвятили тестам. Тем не менее я не слезал с этой троицы и выжал из них что мог. Часть критичных багов было закрыто. Часть логики переработана.

Один за другим, тестировщики отчитывались директору о том, что их устраивает программа.

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

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

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

Теперь немного про плюсы внедрения.

1)Первое это синхронизация между С# и 1С. Директор требовал от меня создания функционала, я же с этим не спешил. Спешил я с синхронизацией. Создавая новый справочник или документ, я пытался хотя-бы частично настроить его синхронизацию. Это я делал скрытно от директора, чувствуя подсознательно что эти вещи надо закрыть прежде всего. И вышло так, что неожиданно для меня, за 2-3 недели до НГ директор объявил, что программист по С# уходит.

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

 

2)Синхронизация с бухгалтерией. Как обычно бывает, после запуска программы практически сразу остро встал вопрос выгрузки данных в бухгалтерию. А там соотв-но конкретные строки закрытия периода и задачи отчетности. И вот к тебе прибегают люди с вопросами и косяками, но у тебя горят сроки по синхронизации. Ад просто. Благо я позаботился о синхронизации заранее. Конечно, не все пошло гладко, но отведенного времени вполне хватило на то чтоб подкрутить ошибки.

3)Печатные формы. Печатные формы всегда делают в самом конце. Когда описан полностью документ. Я же и вовсе не хотел браться за них. Не люблю я это, вот и всё. Муторно.

Тем не менее, я много времени потратил на формы. Делал их так, чтоб люди могли сесть и работать. Я понимал, что времени на правки практически не будет, т.к. фирма перейдет на 1С и менеджеры начнут печатать документы клиентам. Иначе, при критичных ошибках и явных багах работа просто встанет. Я старался сделать так, чтоб в 1й день работы фирмы на 1С, у меня было как можно меньше проблем по всем фронтам. 

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

 

Итак, внедрение завершено. На всё потребовался год работы. С базой работают около 20и человек. Ещё многое нужно сделать и дописать, но главное то, что система работает.

 

Так-же решил выложить картинки того что вышло.

И рассказать по метаданным, было добавлено:

- 5 новых документов.

-19 справочников.

- с десяток отчетов.

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

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

 

Всем спасибо за внимание.

 

 

ERP внедрение логистика

См. также

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

Requirements Modeling Language (RML) - язык, разработанный специально для визуального моделирования требований. При разработке RML существующие модели были модифицированы для упрощения восприятия информации заинтересованными сторонами. В RML используются только простые и интуитивно понятные символы.

12.12.2024    510    0    SerjoginaMaria    5    

5

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

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

04.12.2024    1108    0    bolikov    21    

8

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

В данной статье рассматриваются задачи, которые необходимо решить при поэтапном внедрении 1С: ERP на крупном предприятии. Рассмотрен вариант перехода с успешно функционирующей 1С: УПП. Предлагается обсудить правильность принятых решений.

29.10.2024    817    0    VicCva    1    

4

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Мы провели опрос заказчиков с целью определить степень удовлетворенности внедрением 1С: ERP. Опрос проводился по случайной выборке из списка внедренных решений на сайте 1С. Обработали 121 интервью от 97 компаний. Из выборки мы исключали "показательные внедрения" и крупнейшие холдинги, старались получить срез по "средним" массовым заказчикам. Статья будет интересна сотрудникам отделов продаж и отделов качества фирм, внедряющих 1С, потенциальным заказчикам и всем, кто интересуется статистикой внедрения 1С: ERP. Текст статьи довольно большой, в некоторой степени наукообразный.

16.10.2024    1595    0    Soliton    8    

8

Agile Внедрение изменений Бесплатно (free)

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

13.09.2024    2660    0    glebushka    5    

8

Анализ предметной области Анализ бизнес-процессов Работа с заинтересованными сторонами Бесплатно (free)

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

02.09.2024    1427    0    user1669221    2    

7

Внедрение изменений Бесплатно (free)

Когда при внедрении систем 1С всплывает слово «ГОСТ» – практически всегда речь идёт о документе «Техническое задание». И у большинства внедренцев падает настроение, как только им говорят, что надо «написать ТЗ по ГОСТу». Но опытные кулинары знают, как готовить это блюдо так, чтобы оно оставило после себя приятное послевкусие, а не горькое разочарование. О собственных рецептах приготовления документации по ГОСТу пойдет речь в статье.

21.08.2024    2963    56    Laya    3    

22

Анализ предметной области Анализ потребностей и поиск решений Бизнес-аналитик Руководитель проекта Управленческий учет Бесплатно (free)

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

19.08.2024    1780    0    SergeyN    0    

6
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. genayo 03.12.18 13:57 Сейчас в теме
Автор молодец :) Хотя, конечно, то, что всё взлетело при такой работе со стороны заказчика - несколько удивительно...
CheBurator; +1 Ответить
2. dm_romanov.idm 03.12.18 15:03 Сейчас в теме
История интересная и поучительная, надеюсь автор не выгорел.
ТЗ можно не писать, но просто необходимо вести реестр задач с инициаторами, кратким описанием и приоритетом.

А за чем директору была нужна программа на 1С один в один, как уже написанная и используемая на C#?
Причём здесь ERP?
3. dmitryburykin 8 03.12.18 15:25 Сейчас в теме
Автор!
Упоминание ERP в заголовке некорректно.
Это же проф.ресурс а не желтая пресса...
ZOMI; Proftext; ИНТЕГРА; yacobs; IROKEZ91; zeegin; +6 Ответить
4. KHoroshulinAV 171 03.12.18 15:38 Сейчас в теме
Я знал что польется говнецо, но не думал что такое низкопробное.
Для особо одаренных привожу определение:
Аббревиатура ERP происходит от английского выражения Enterprise Resource Planning, что дословно означает планирование ресурсов предприятия.
5. dmitryburykin 8 03.12.18 15:58 Сейчас в теме
(4) ну а со своими медицинскими проблемами наверное лучше на другой проф. форум...
6. Xershi 1555 03.12.18 16:06 Сейчас в теме
(4) по комментам понял что внедряли не УП 2. А что-то другое, ну тут уже все что угодно выстрелить могло))
8. genayo 03.12.18 16:49 Сейчас в теме
(4) Да они просто тебе завидуют :)
10. Константин С. 675 03.12.18 17:17 Сейчас в теме
(4) вот именно ни слова про Enterprise Resource Planning, только как л****ся при разработке софта с подсчетов ошибок.

Главное не повторять эти ошибки после.
11. dmitryburykin 8 03.12.18 18:15 Сейчас в теме
(4) Автор, если так поверхностно по переводу аббревиатуры рассуждать о ERP, то для Вас и Excel страничка - ERP.

Директору, на самом деле - респект.
За мужество, за веру!
15. vakham 21 05.12.18 14:24 Сейчас в теме
(11) Директор - идиот. Надо быть дебилом, чтобы всё замкнуть на себя. Он полы по вечерам не моет? А то вдруг утром грязно, клиенты "фи" скажут.
Делегировать слабо? Или дебилов набрал?
rovenko.n; +1 Ответить
7. fishca 1259 03.12.18 16:45 Сейчас в теме
Так взлетело?
Что за конфигурация?
9. zeegin 118 03.12.18 16:57 Сейчас в теме
> нельзя называть никаких сроков, даже примерных, пока ты точно не поймешь, с чем столкнулся

Сроки давать надо. На конкретный спринт с конкретными задачами, так, чтобы выполнялся он не более 2х недель.

> Мы не писали ТЗ

К тому моменту когда будет реаоизовано ТЗ бизнесу будет требоваться уже нечно другое. Надо писать не ТЗ а бэклог задач, желательно с декомпозицией не более 2 часов на задачу.

> требовать тестировщика из штата сотрудников

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

> Никогда не сажайте людей на новую систему без обучения!

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

> Не нужно слушать руководство всегда. Все же специалисту часто виднее то, что касается его узкого направления работы

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

> Имеет смысл постараться предусмотреть те моменты, которые могут быть критичными при запуске

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



Что я могу дать в резюме: Вы справились с задачей, но Вы сделали неправильные выводы. Это связано с недостатком управленческого опыта. По статье невозможно оценить уровень Вашего владения архитектурой, но на управление ресурсами следует уделить внимание и посмотреть тематические курсы и записи конференций.
ZOMI; oleg-m; mirco; user811769; &rew; CSiER; SoftIce; vadim92; A_Max; JohnConnor; dmitryburykin; +11 Ответить
18. rovenko.n 06.12.18 16:05 Сейчас в теме
(9)
На конкретный спринт с конкретными задачами, так, чтобы выполнялся он не более 2х недель.

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

(9)
тесты писать по поведению, автоматизированные. Тогда тестировщик не нужен.

Написание тестов - тоже очень большой кусок работы. А программист у нас один. Или вы это не прочли?
(9)
тогда не будет требоваться сложного обучения.

1С - это система учета. Пользователь создает документы и вносит в них реквизиты. В каждом документе от 1 до 100 реквизитов. Каким образом можно создать "понятный интерфейс", чтобы человек сразу всё понял?

(9)
удержать единственного владеющего информацией программиста.

То есть вы предлагаете программисту еще и за персонал Заказчика отвечать?
(9)
Вводить в эксплуатацию программу надо блоками, а не сразу всю.

Так автор же сказал, что это не его идея.
Всё то, что вы говорите, работает в теории, на практике сраки горят, всё нужно одновременно, обучение необходимо, пользователи тупят.
19. zeegin 118 06.12.18 20:26 Сейчас в теме
(18)
Задачка: возьмите вот это вот всё и перенесите точно так же в другую систему.


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

Спринты как раз и нужны для того, чтобы писать когда ты НЕ знаешь спицифику, чтобы быстро можно было изменять поведение от первоначально оговоренного. Потому что задачи ты получаешь готовыми завершенными блоками и всегда есть четкое понимание что ты делал, зачем и на что конкретно потратил время.

Написание тестов - тоже очень большой кусок работы. А программист у нас один


Кто пишет feature файлы ?
- менеджер проекта - если обнаружил что заказчику необходимо новое поведение;
- бизнес или системный аналитик - на основе собранных требований и технических заданий;
- ведущий разработки - если обнаружил, что требования недостаточно структурированы;
- архитектор или эксперт 1С - если текущие сценарии некорректно спроектированы с точки зрения метаданных.
- тестироровщик - когда пишет сценарии для проверки поведения

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

Каким образом можно создать "понятный интерфейс", чтобы человек сразу всё понял?


Ну как минимум выучить стандарты, и прогнать чек лист по своим интерфейсам отсюда https://its.1c.ru/db/v8std/content/-2145783081
А как правильно - это сначала прототипировать, согласовывать, а потом только приступать к реализации.

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

То есть вы предлагаете программисту еще и за персонал Заказчика отвечать?


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

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


Если делать все в хаосе, то да, так и будет.
Послушайте курс "Управление проектами" - это бесплатно https://openedu.ru/course/hse/PRMN/
Ну и я не советую то, что не применяю на практике ;)
ZOMI; VKuser61601951; mirco; dm_romanov.idm; user811769; +5 Ответить
24. VKuser61601951 24.04.23 06:51 Сейчас в теме
(19) Ну хаос, это тоже одна из моделей разработки, имеющая право быть. Сплошь и рядом много чего рождается из хаоса и вполне потом жизнеспособно. А "открытое образование" это действительно одна из лучших платформ для самообразования.
12. CheBurator 2684 05.12.18 01:29 Сейчас в теме
Автор - молодец! Асилил!
Автору +100 в карму.
Все описанное знакомо и не один раз.
Aggressorak; Barbos; +2 Ответить
13. Stim213 416 05.12.18 11:08 Сейчас в теме
Очень актуально, занимаюсь подобной работой. Если б не упоминание логистики, подумал бы, что у меня этот же клиент)
14. KHoroshulinAV 171 05.12.18 11:46 Сейчас в теме
Очень рад что смог помочь. Удачи!)
16. vakham 21 05.12.18 14:30 Сейчас в теме
Чтиво интересное, но старо как мир. Ошибки были предсказуемы, следствия - тоже. Автору - орден за мужество, но больше так тупо не поступай. А если директор баран, то учи его как руководить надо. Нехер директору программы тестировать.
"Не дело комдиву в атаку ходить!" (с)"Батальоны просят огня. Не его это дело. Дело комдива - с картой сидеть и выезжать на место, проверяя свою работу и работу подчинённых. А если дебил, то тогда согласен... Если просрал наступление, то шашку на голо и вперёд в атаку на пулемёты.
rovenko.n; +1 Ответить
17. ids79 8565 06.12.18 07:49 Сейчас в теме
Описанная картина стара как мир!
На первом моем крупном внедрении было все в точности также. И только усердие и желание во что бы то ни стало завершить проект, привело к успеху.
Так что Автору респект, а всем кто попал в аналогичную ситуацию - терпения и удачи.
К сожалению на чужих ошибках мы учимся гораздо реже, чем на своих.

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

Спасибо за статью и удачи с новыми проектами.
CSiER; rovenko.n; +2 Ответить
20. СергейК 51 07.12.18 19:12 Сейчас в теме
Спасибо, интересно.
А напишите данные получившейся конфигурации для оценки возможностей одного разработчика все сделать самому.
Думаете, то что получилось, это средний максимум для одного человека в год?
21. KHoroshulinAV 171 10.12.18 09:33 Сейчас в теме
Трудозатраты измерять сложно. Можно сделать 100 документов а можно сделать 5. И по трудозатратам оно будет равноценно.
22. пользователь 22.07.20 21:05
Сообщение было скрыто модератором.
...
23. VKuser61601951 24.04.23 06:15 Сейчас в теме
Недавно общалась с одним из таких же "занимающимся .......... практически о всему региону". Только там клиент хотел уже (наконец то собрался со средствами, чтобы перейти с КА, которая успешно, с небольшими регулярными изменениями работала аж с 2006 года на 1С:ERP). Мои навыки и опыт устраивали, мы давно знакомы и необходимые изменения до настоящего момента в 1С КА (Предприятие 7.7) дело рук моей команды. Но клиент категорически был не согласен провести предпроектное обследование на тему так ли уж надо переходить на 1С:ERP, может быть досточно будет конфигурации попроще и подешевле не только в приобретении, но и в сопровождении? То есть с одной стороны он финансово готов (это как то разведала ближайшая фирма из франчазей), но с другой: Ах! как хочется поэкономить. И меня же еще обвинил в вымогательстве, я же и так все знаю как оно есть, зачем обследование? И никакие доводы не помогли. К чему я этот комментарий написала? Да к тому, что если вы, собственники, доверяете специалисту, то и доверяйте. А если нет, то ищите другого. И,кстати, очень уж рьяно работают продавцы конфигураций 1С:ERP. Молодцы! Всем навяливают, кому надо и кому не надо. Благо, у многих из вас, денег уже и куры не клюют.
Оставьте свое сообщение