Pull to refresh

Comments 10

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

Не верьте в обещания, типа “как раз сейчас мы готовим новую версию руководства пользователя” — поверьте — никто ничего “как раз сейчас” не готовит. Если четких манов нет — значит это кому-то нужно…

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

Смело звоните в эти вузы и спрашивайте об эффектах от внедрения, пусть коллеги поделятся опытом эксплуатации системы, попросите оценить удобство ее каждодневного использования, вам не откажут. При неудачном внедрении поинтересуйтесь, почему система “лежит” или используется на 10%, что стало этому причиной — может быть подвел разработчик, возможно, что система показала себя не очень дружелюбной к пользователю или не оправдала ожиданий у руководства вуза или причиной неудачи стали конечные пользователи и их низкий уровень компьютерной грамотности. Таким вот образом вы получите самую объективную характеристику системы.

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

Исходя из статьи хотелось бы задать вам вопрос.
1) Какова причина низкого уровня пользования системой и удалось ли вам ее преодолеть?
2) Удалось ли вам получить от других клиентов поставщика полезные отзывы? На каком этапе выбора системы вы с ними контактировали?
1) Преодолеть низкий уровень использования системы не удалось, как вы понимаете. Причин много, из основных можно отметить карявость самого купленного решения, низкий уровень компьютерной грамотности потенциальных пользователей, отсутствие у них мотивации к работе в erp.
2) Мы практиковали практику общения с профильными вузами-пользователями системы. К сожалению, мы начали это слишком поздно — на моменте внедрения. Мнения о недостатках системы и проблемах, в основном, сходились. Я бы не стал говорить, что «не все клиенты готовы поделиться подобной информацией» — у нас вышло как раз наоборот.
Не стоит везде искать подвох.

в нашем случае — стоило…
Было бы великолепно, если бы господа, минусующие пост, писали в комментариях мотивацию к этому действию.
Пост сырой. ERP то строчными, то прописными — вы бы хоть определились со стилем.
Было бы неплохо хоть раз эту аббревиатуру расшифровать, всё-таки пост не только в профильный хаб.
Стиль изложения своеобразен — много длинных предложений, в итоге текст тяжело воспринимается.

Да и вот еще что, пост о высшем образовании от сотрудника вуза, а в слове «дилемма» две ошибки допущено…
Поправьте, пожалуйста.
1) Хм, прописные и строчные буквы,… Совсем не говорит о «сырости», просто писал несколько дней, вот и все.
2) Поправил, спасибо.
Если честно, читать тяжело. Можно, но тяжело:
Написание собственной erp — задача не из простых, решить которую могут порой лишь технические вузы, кующие кадры и для самого себя тоже, однако, при принятии решения о написании своего продукта, руководство в дальнейшем сталкивается с такой тривиальной ситуацией, как текучка кадров, в результате чего новый программист, порой, не может разобраться в коде предыдущего и начинает переписывать какие-то части с нуля, что тянет за собой клубок проблем

Вы пишете:
На хабре есть не одна сотня статей о erp, но в разрезе внедрения системы в вузе я не нашел ни одной.

Но в посте нет ни одного упоминания о какой-либо ERP-системе, одни лишь общие рассуждения и советы. И, на мой взгляд, советы довольно очевидные и универсальные для всех областей применения: «сначала думай, потом делай».
Но в посте нет ни одного упоминания о какой-либо ERP-системе, одни лишь общие рассуждения и советы.

Я умышленно не стал писать ни о той системе, которую использует наш вуз, ни о других.
Статья о проблеме выбора и внедрения ERP.
Факт, что Америку в выборе ERP не открыть. Гуманитарные вузы, как правило, чаще всего сталкиваются с проблемами при использовании этих продуктов. Причины этого я и постарался изложить и, возможно, предостеречь от ошибок.
Если честно, читать тяжело. Можно, но тяжело

Возьму на заметку.
«сначала думай, потом делай»

Этот совет очевиден и универсален, согласен, но дьявол кроется в мелочах…
В целом картина описывает любое внедрение любой системы на любом предприятии.
Везде необходимо в первую очередь бороться с хаосом. Если автоматизировать хаос — получится автоматизированный хаос.
Ну и саботаж, куда без него.
А как должен выглядеть «документ, распоряжение, приказ»? Какие пункты он должен описывать и какие полномочия давать внедренцу?
Я не знаю, существует ли какая-либо универсальная форма этого приказа, но уверен, что во главе внедрения должен быть человек, который может в данном учебном заведении не только пряники раздавать, но и кнуты, если потребуется. Это личное мнение.
Sign up to leave a comment.

Articles