С чего начать внедрение

[Странник 6]

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

Пожалуйста, про Бонапарта не напоминайте, а скажите своё ИМХО по поводу того, какой из лоскутиков стоит сделать как бы корневым?

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

1. обучение конструкторов работе в выбранном CAD по стандартам конкретного предприятия и установка этого CAD всем обученным людям;

2. покупка PDM-системы и размещения в ней единого хранилища всякой стандартщины, типа метизов, радиоэлементов и т.п;

3. обучение конструирующего народа и установка клиентов PDM-системы на всех рабочих местах;

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

5. пока конструктора создают свои электронно-цифровые макеты (ЭЦМ) и электронные структуры изделия (ЭСИ), а IT-шники дополняют по их заявкам базу данных предприятия провести обучение технологов технологическому пакету и PDM, с таким расчётом чтобы готовые ЭСИ сразу пошли в дело и начали обрастать ТД;

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

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

Разумеется, все эти системы должны быть подогнаны друг к другу заранее, на этапе пилотного проекта или даже собственно разработчиками единой PLM, стандарты предприятия (СТП) созданы тоже по итогам пилотного проекта, а бизнесс-процессы предприятия оптимизированы и сами по себе не считаясь ни с чьими привычками и амбициями.

Итак, уважаемые коллеги, чем же предлагаемая схема плоха?

[labslo 0]

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

Получиться что документооборот будет ходить по нескольким системам и придется делать стыковку между ними.

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

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

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

1. Берем ВСЕ документы (сюда входят и планы работ) которые ходят например в конструкторском подразделении и описываем: какой формат, кто вносит в них данные, откуда они поступают, как они проходят внутри подразделения, куда они потом уходят. И точно также по всем подразделениям которые будут участвовать в документообороте.

2. Из того что получиться в 1 пункте выделяются ключевые данные (потому как эти данные будут ходить по разным системам):

ключевые данные в принципе следующие: сроки выполнения работ по подразделениям предприятия, форма и размеры изделий (CAD-данные),наименование и обозначения изделия и его состав, материалы которые идут на изготовление деталей и сборок(сюда входят как основные материалы указываемые конструктороами так и вспомогательные материалы указываемые технологами, наименования технологических операций, время на операцию причем должны быть указаны 3 его составляющие, осноснове. вспомогательтное, подготовительно-заключительное, отдельнооборудование на котором изготавливается, инструмент используемый при изготовлении, приспособления используемые при изготовлении, код профессии рабочего, количество рабочих на операции, разряд работ, СОЖ на операции, тара, средства индивидуальной защиты, транспортные механизмы используемые при межоперационных перемещениях.

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

4. Каждая служба делает свои "портянки" которые показывают документооборот внутри них.

5. Анализ документооборота и его корректировка с целью оптимизации количества документов и по возможности перевод их в электронный вид.

III. Выбор систем на основе которых будет создан документооборот и систем с помощью которых будут создаваться и обрабатываться данные. Желательно пригласить какую либо ИТ фирму которая уже занималась такими проектами в качестве консультантов. Часто в этот момент ИТ-фирма даже не берет деньги за такое консультирование. Системы могут быть не только покупными но и собственной разработки.

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

V. Окончательный выбор систем и делается еще одна "портянка" в которой документооборот уже накладывается на программы.

VI. Установка систем и обучение ИТ-служб. Ввод пользователей систем.

VII. Обучение. Перед конструкторскими подразделениям нужно обучит тех кто планирует эту работу. Если на предприятиии есть подразделение которое планирует всю подготовку производства, то именно их надо учить в первую очередь. Конструкторов и технологов надо учить паралллеьно так как им вместе создавать ключевые данные. По началу может быть так что в PDM-системе не будет каких то конструкторских данных, но технологи уже будут работать в ней. Желатьельно чтобы конструктора и технологи работали в одной системе тогда получиться что ключевые данные храняться в одной системе. и с ними легче работать, также желательно чтобы вся подготовка производства находилась в одной системе.

VIII. Будем исходит из того что PDM-система будет охватывать всю подготовку производства. В ней необходимо создать процессы электронного документооборота, проверить их, начать прохождение документов по процессам. Корректировка процессов по результатам работы.

Ну а дальше точно также остальные подразделения.

[Странник 6]

labslo, ваши постулаты №I...VI фактически охватывают то, что у меня скромно названо пилотным проектом и выводами по его итогам. Хотя я и не со всеми моментами там согласен, но всё равно это очень полезное дополнение, спасибо.

Все выявившиеся разногласия по этим пунктам обсудим чуть позже (ввиду большого объёма информации), а начнём с уже постпилотной работы.

VII. Обучение. Перед конструкторскими подразделениям нужно обучит тех кто планирует эту работу. Если на предприятиии есть подразделение которое планирует всю подготовку производства, то именно их надо учить в первую очередь. Конструкторов и технологов надо учить паралллеьно так как им вместе создавать ключевые данные. По началу может быть так что в PDM-системе не будет каких то конструкторских данных, но технологи уже будут работать в ней. Желатьельно чтобы конструктора и технологи работали в одной системе тогда получиться что ключевые данные храняться в одной системе. и с ними легче работать, также желательно чтобы вся подготовка производства находилась в одной системе.

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

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

Таким образом, если на заводе планово-производственный отдел (ППО) изначально уже имеет некие опорные цифры, то в КБ что-либо наперёд сказать труднее в разы, если не на порядок. Да и как возьмёт ППО результаты работы за подотчётнй этап, если ни у кого другого система ещё не внедрена?

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

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

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

[labslo 0]

Я работаю на предприятии где есть все и конструктора и технологи и производство.

Если все в одном то лучше чтобы все работали в одной системе без разделения.

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

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

[Странник 6]

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

А за "т.контр." кто подписывает такую КД? Прямо в КБ кто ни будь?

[brigval 690]

1. Берем ВСЕ документы (сюда входят и планы работ) которые ходят например в конструкторском подразделении и описываем: какой формат, кто вносит в них данные, откуда они поступают, как они проходят внутри подразделения, куда они потом уходят. И точно также по всем подразделениям которые будут участвовать в документообороте.

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

[Странник 6]

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

Например, схемотехники сидят с 10 версией ACAD (той ещё, что под DOS) и современной ей версией PCAD (к тому же нагло утверждая, что работать не умееют), хотя сами в кармане таскают какие ни будь айфоны с мобильным интернетом и прочими прелестями. Будете подстравать под них систему?

[Sten 2]

Итак, уважаемые коллеги, чем же предлагаемая схема плоха?

Плоха тем,что сначала конструктора учатся работать в CAD без PDM, а потом начинают учиться работать в PDM. Даже отбросив гемморой по миграции даных, который на порядки больше,чем это представляется изначально, то такой подход имеет мало шансов на реализацию. Работа в голом CAD и CAD под PDM отличаются сильно. Как показывает практика российских предприятий, те кто сначала решает конструкторов сажать на CAD,а потом приучать к PDM - лишаются большой части волос на голове:) Потому что рвут их на себе:) Я не знаю и не хочу разбираться в чём затык, скорей всего в ментальности, но это характерные грабли, на которые уже наступили десятки предприятий и сильно об этом жалели.

А второй косяк - это постулат о приказном порядке. Не работает. Нигде. Никогда. И не будет. Так кажется проще, думается,что приказами можно сломать любое сопротивление. Ан нет же. Легкий ээфект на раннем этапе, вызывающий эйфорию и стойкое убеждение в том, что такой подход работает,но потом реальность даст фэйсом об тэйбл. Пока от низа до верха не будет четкого осознания, понимания и ясности, никакие приказы ничего не сделают.

[Странник 6]

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

Так это осознание придёт не ранее чем лет через 20, если вообще придёт когда ни будь. Ибо даже 40 летний начальничек начинает сильно опасаться за своё кресло, стоит лишь предложить что либо новое или просто ему конкретному непонятное... что уж говорить о тех, кому под 60.

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

[labslo 0]

Плоха тем,что сначала конструктора учатся работать в CAD без PDM, а потом начинают учиться работать в PDM. Даже отбросив гемморой по миграции даных, который на порядки больше,чем это представляется изначально, то такой подход имеет мало шансов на реализацию. Работа в голом CAD и CAD под PDM отличаются сильно. Как показывает практика российских предприятий, те кто сначала решает конструкторов сажать на CAD,а потом приучать к PDM - лишаются большой части волос на голове:) Потому что рвут их на себе:) Я не знаю и не хочу разбираться в чём затык, скорей всего в ментальности, но это характерные грабли, на которые уже наступили десятки предприятий и сильно об этом жалели.

А второй косяк - это постулат о приказном порядке. Не работает. Нигде. Никогда. И не будет. Так кажется проще, думается,что приказами можно сломать любое сопротивление. Ан нет же. Легкий ээфект на раннем этапе, вызывающий эйфорию и стойкое убеждение в том, что такой подход работает,но потом реальность даст фэйсом об тэйбл. Пока от низа до верха не будет четкого осознания, понимания и ясности, никакие приказы ничего не сделают.

Именно с таким случаем столкнулся. Закончилось тем что те кто смог понять выгоды для себя в виде CAD+PDM+отслеживание изменений те продолжают работать, а остальные только ищут способа как не делать модели , а класть в PDM только чертежи в лучшем случак, в худшем случае открыть PDM только для того чтобы посмотреть что там сделано.

Например, схемотехники сидят с 10 версией ACAD (той ещё, что под DOS) и современной ей версией PCAD (к тому же нагло утверждая, что работать не умееют), хотя сами в кармане таскают какие ни будь айфоны с мобильным интернетом и прочими прелестями. Будете подстравать под них систему?

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

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

[Елена 116]

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

[Странник 6]

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

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

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

Собственно потому и говорю, что начинать нужно с тихого внедрения CAD и обязательного ремоделлинга.

P.S. Если к CAD сразу прилагается хорошая PDM, то это конечно оптимальный вариант, но к сожалению не всегда имеющий место быть в реальности.

[volodja 77]

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

Верно, к вышесказанному добавлю: предварительно неплохо бы отправить заинтересованных (ну пусть не всю группу, но основных людей) в штаб-квартиру этой самой CAD/PDM-фирм(ы) на пару дней для демонстрации возможностей. Или согласовать с ними, у клиента работающий проект посмотреть. Обычно! западники (ну по крайней мере наша фирма и те, которые я знаю) в этом охотно помогают и показывают.

[Странник 6]

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

Кстати, тут тоже есть немалый "подводный камень".

Фирма-поставщик может предложить в качестве эталона и не столь уж достойного подражания клиента, при этом сколько бы собственная экспертная группа не сигнализировала бы и даже не всё одно руководитель в ответ будет повторять одно и тоже

но ведь на предприятии N это работает именно так

[volodja 77]

Кстати, тут тоже есть немалый "подводный камень".

Фирма-поставщик может предложить в качестве эталона и не столь уж достойного подражания клиента, при этом сколько бы собственная экспертная группа не сигнализировала бы и даже не всё одно руководитель в ответ будет повторять одно и тоже

Не знаю, может быть. Но солидная фирма не должна бы предложить.... Кроме того, это не означает, что надо слепо 1:1 копировать, надо основную идею посмотреть и как может быть реализовано. Опять же вы априори предполагаете такого руководителя, который будет также тупо следовать тому, что он увидел и понял/не понял. Так что у вас тут проблема больше упирается в головы, а не в технологии....

[Странник 6]

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

Не предполагаю, но имею некоторый опыт, однако.

Например, некоторое предприятие доказывает что у них всё хорошо и даже само искренне в это верит. А ковырнёшь их где ни будь на конференции и окажется, что образно говоря у них задачи проще на порядок, а организация делопроизводства и без всякой автоматизации лучше на 2 порядка. Только попробуй это объяснить человеку, что сам и создал те самые два порядка сложности из-за бизнесспроцессов. Кстати, базовый CAD выбирал он же, из соображений

погаже, да подешевле.

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

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

[volodja 77]

Не предполагаю, но имею некоторый опыт, однако.

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

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

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

НУ это уже ваши "внутренние" проблемы и спрашивать совета на эту тему совершенно бесполезно. Как уже говорил, "тут проблема больше упирается в головы, а не в технологии...".

[Route 2]

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

Схема вполне сносная.

Только выражение "все эти системы должны быть подогнаны друг к другу" портит все. Мы же с Вами прекрасно знаем что данное условие не выполнимо

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

В «каше» каждый сотрудник на предприятии будет радостно «работать» в своей «любимой» системе. А проблему синхронизации данных повесят на IT отдел, который всю жизнь будет заниматься научной работой по корреляции баз данных, до тех пор пока актуальность данных в базах не упадет ниже 50 %. Передача данных из одной системы в другую проблема №1 на наших предприятиях. Именно из за этой проблемы и возникает желание у многих «организации прохода докУментов по цепочке администрация - конструктор - технолог - производство - бухгалтерия - администрация в электронном виде». . Кадый будет ждать как и раньше своей очереди в цепочке, толко теперь с электонным документом. Это утопие.

А самое главное, что и показать в такой «каше», даже с документооборотом, руководству практически нечего! Руководству конечно понятно что надо идти «вперед к нано-технологиям» , но автоматизация ради автоматизации – это бред .

По этому главное что нужно сделать в начале внедрения – ответить людям на предприятии (а еще лучше себе) на вопрос «Какова конкретная цель внедрения?» .

И если на этот вопрос вы отвечаете: «Автоматизация КТПП», лучше тогда внедрением какой либо системы и не заниматься вовсе.

[sceptic 0]

По этому главное что нужно сделать в начале внедрения – ответить людям на предприятии (а еще лучше себе) на вопрос «Какова конкретная цель внедрения?» .

И если на этот вопрос вы отвечаете: «Автоматизация КТПП», лучше тогда внедрением какой либо системы и не заниматься вовсе.

Полностью согласен. И вообще, по моему мнению, ряд действий по внедрению PDM-PLM-ERP-??? (о CAD вообще не говорим) стоит выстроить так:

1. Цель

2. Формирование инициативной группы

3. Формулирование функций

3. Описание процессов

4. Анализ существующих систем

5. Согласование с руководством выбора конкретной системы (деньги, ресурсы, сроки и т.п.)

6. Работы по внедрению, адаптации, разработке своей системы и т.д. и т.п.

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

[Странник 6]

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

Например, предприятие только сканирует и привязывает к вручную созданной ЭСИ старые калечные чертежи, при этом не создавая ничего нового. CAD-овскую PDM систему они конечно понавтыкали буквально везде, вплоть до бухгалтерии, и даже пользуют WORKFLOW, вот только 3D моделей как таковых у них фактически нет.

Ребята действительно искренне верят, что у них идёт автоматизация, но ведь в самом то деле это далеко не так.

Схема вполне сносная.

Только выражение "все эти системы должны быть подогнаны друг к другу" портит все. Мы же с Вами прекрасно знаем что данное условие не выполнимо.

Главная причина таковой невозможности это постоянное обновление версий систем.

Однако, почему бы не остановиться на каком либо определённом наборе релизов лет на 7...8...9...10 и только посмеиваться в ответ на все заявления продавцов софта о ретроградстве?

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

А самое главное, что и показать в такой «каше», даже с документооборотом, руководству практически нечего! Руководству конечно понятно что надо идти «вперед к нано-технологиям» , но автоматизация ради автоматизации – это бред .

Во интересно то как, а повышение точности итерации при разработке новой техники с соответствующим уменьшением затрат на отработку и общее сокращение сроков уже как бы не в зачёт?

Синхронизация баз данных это конечно вопрос не из лёгких, но почему считается, что его нельзя решить на основе точного ЭЦМ с максимально упрощеным программными средствами вводом самим конструктором/технологом ключевых атрибутов?

Например, просто вводя название файла модели в строгом соответствии с СТП вполне можно незаметно получить атрибуты <Обозначение>, <Наименование> и <Разработал>, если немного подумать, то и <Первичное применение>, а если ещё чуть-чуть помудрить с шаблонами то можно тут же идентифицировать тип обработки, точности, заготовку и материалы и т.д. Как именно сие реализовать в максимально комфортном для пользователя виде - это и есть собственно работа IT специалистов, а передать дальше по цепочке весь этот джентельменский набор и сейчас вполне возможно, хотя бы посредством html.

По этому главное что нужно сделать в начале внедрения – ответить людям на предприятии (а еще лучше себе) на вопрос «Какова конкретная цель внедрения?» .

И если на этот вопрос вы отвечаете: «Автоматизация КТПП», лучше тогда внедрением какой либо системы и не заниматься вовсе.

"Автоматизация КТПП" это и не цель вовсе, но средство, при чём средство сие в самом деле и называется то иначе.