samanta_sДоброго времени суток. Так сложилось, что жизнь меня закинула старшим разработчиком в крупную контору занимающуюся производством и сбытом металлопроката. Сразу честно признаюсь - произошло это случайно. До сих пор мой опыт разработки состоял из допустим - каталог CD у какого нибудь меломана и т.п. Теперь от меня ожидают комплексных решений по автоматизации.
Предположу следующее: раз вы смогли устроится на такую позицию не имя опыта работы на таких проектах и понимания предметной области, значит у вас есть ярко выраженные лидерские качества и задатки менеджера. Если это не так то советую искать работу по вашим знаниям и опыту и не замахиваться на "нашего Вильяма".
Если так то наймите себе в заместители профессионального специалиста имеющего опыт этой самой комплексной автоматизации, еще лучше в этой самой области производство и сбыт металлопроката. Ему поручите реализацию всех этих задач. Сами выполняйте роль руководителя проекта, заместитель будет выполнять роль технического руководителя проекта.

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

Примеры проблем:
Закупки и запасы
- не систематизирована номенклатура ТМЦ
- нет актуальных оборотов по взаиморасчетам с поставщиками
- нет актуальных остатков по запасами

Производство
- не систематизирована номенклатура ТМЦ и готовой продукции
- не установлены нормы расхода ТМЦ в производства
- не отражается выпуск продукции

Учет
- нет актуальных остатков по конкретным системам и в комплексе
- в различных системах различная кодификация
- в различных системах различные подходы к учету движения номенклатуры

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

На основе групп проблем разрабатываете планы устранения.
На основе понимания по процессам и лоскутам решаете что делать с системой:
1. Дорабатывать дальше
2. Часть процессов перенести в "новую систему" (с перспективой замены всей системы или большей её части)
3. Менять всю систему на другое решение.

Предположу что в вашем случае больше подходит вариант 2, поскольку 1 - это скорее всего тупик, а на 3 никто вам не выделит ресурсов. Судя по всему классический случай "многолоскутной автоматизации", здесь основная стратегия "укрупнение лоскутов".
Сращивать нужно смежные лоскуты и начинать с тех лоскутов объединение которых соответствует основным бизнес процессам, опять же в зависимости от приоритетности проблем.
Для серийного производства лучше начинать с процессов продаж и учета. В производство особо лезть не надо, главное корректно систематизировать номенклатуру выпускаемых изделий, отразить выпуск продукции и наладить системную работу с номенклатурой продукции, работу с клиентской базой, взиморасчеты и т.п.
Например, осуществлять продажи без учета остатков продукции и взаиморасчетов очень проблематично, поэтому нужно в первую очередь обеспечить поддержку этих процессов в комплексной системе. Осуществлять закупки ТМЦ: без учета поступления, остатков и взаиморасчетов с поставщиками - в единой системе также проблематично.
Выбор стратегии также зависит от того что за производство и что за продукция.
По мере перевода процессов в более комплексные системы или систему, вы наберетесь необходимого опыта, завоюете авторитет и сможете уже выстраивать другой уровень взаимодействия с руководством и предлагать более комплексные и выверенные решения.

samanta_sИМХО нужно начинать на уровне правления, привлекать для консультации работников всех уровней, дабы создать картину "вот то что у нас есть, а теперь давайте говорить о том что Вы хотите". Я правильно рассуждаю?
Да, правильно.
Но раз над вами три начальника, а вы "разработчик" то это не совсем ваша работа. По сути нужно делать анализ бизнес-процессов с определенным уровнем детализации, и выявлять несоответствия или избыточность процессов.
Выполнять перепроектирование процессов (есть модное слово "реинжиниринг") с учетом:
- цепочки сквозных бизнес-процессов
- возможности поддержки процессов информационными системами
- возможностей автоматизации рутинных операций.
В любом случае без привлечения аналитика на проект или в команду и без воли и поддержки руководства, без полномочий все эти задачи в комплексе не решить.

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

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

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