Добре знаю систему BAS ERP. Маю успішні проекти її впровадження від А до Я в якості аналітика і організатора, зокрема, після невдалого впровадження відомим інтегратором.

Маю сертифікати Професіонал та Спеціаліст із управлінського обліку в BAS ERP.

Маю досвід програмування в BAS ERP: вдосконалення стиковки для інтеграції з Медком, зовнішні звіти і обробки, СКД, запити.

Маю досвід наведення ладу у різних ділянках вже впроваджених BAS ERP, зокрема, у виробництві. Наведу пару прикладів:

Приклад наведення ладу у виробництві.

Кілька років виробнича компанія працювала в BAS ERP без достовірної виробничої собівартості, із незрозумілими залишками незавершеного виробництва, проблемами з розподілом виробничих витрат, програмними помилками, і недостовірною звітністю. Головбух щомісяця закривала 231 рахунок ручною проводкою, не розуміючи, що там за залишки.

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

І зясував ряд причин: помилки користувачів (по суті методологічні помилки, які дозволяли користувачам робити помилки), помилки розробки (самостійно розроблений функціонал некоретно працював, записувалися некоректні дані в регістри), невірно налаштовані параметри системи.

Ситуацію ускладнювали невдалі безсистемні (точкові) спроби щось виправити.

Я розписав всі виявлені недоліки, їх причини і способи усунення. В кілька етапів.

В результаті ми разом із аналітиками і розробниками цієї компанії виправили всі помилки. Цей проект тривав кілька місяців.

Крім того, я запропонував ряд оптимізацій, які були упішно реалізовані.

Приклад наведення ладу у взаєморозрахунках із контрагентами.

Велика дистрибуційна компанія із власною роздрібною мережею працювала в BAS ERP без достовірної аналітики про стан розрахунків із контрагентами.

Я провів аналіз, виявив причини, склав план дій, організував розробку для виправлення багів і вдосконалення функціоналу, а також організував зміни в концепції розрахунків з контрагентами (перехід на нову логіку в працюючій системі із сотнями користувачів і тисячами документів за день).

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

Приклад транспортна таблиця.

В одному проекті BAS ERP, який до мене не зміг запустити інтегратор, користувачі просили реалізувати в новій системі «транспортну таблицю» по аналогії з екселем, в якому вони вели складську і транспортну логістику.

І команда інтегратора намагалася розробити окремий модуль в новій системі.

Я детально проаналізував процеси, підібрав потрібні параметри системи для складу і номенклатури (в розрізі серій і кодів УКТ ЗЕД), змоделював ланцюг документів і транспортна таблиця запрацювала в BAS ERP з коробки.

Те, що просять зробити користувачі, треба завжди просіювати через призму можливостей нової системи, бо користувачі просять як звикли, а звикли – як було в старій системі.

Чим можу бути корисний.

Можу бути корисним на будь-якій стадії впровадження чи експлуатації систем ERP та електронного документообігу. В основному працював із системами 1С\BAS, але готовий займатися і іншими ERP\СЕДО системами.

Вмію находити і реалізовувати рішення, які працюють.

Обожнюю цифровізацію і автоматизацію і спрощення, які вони приносять.

Отримую задоволення, коли спостерігаю, як результатом моєї роботи є економія часу або більш впорядкований процес (менше помилок, більше достовірної інформації, швидша робота).

Взагалі мені подобається аналізувати і відкривати закономірності, а також втілювати їх в життя. Природна цікавість, схильність аналізувати і робити висновки, а також широкий кругозір підказують мені нестандартні ідеї ефективної оптимізації.

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

Мікроспрощення

Напишу ще пару прикладів невеличких спрощень, яке мені подобається.

Вони показують мій підхід до вирішення окремих задач.

Суть його в тому, щоб добратися до суті :)

А також показують мій підхід до опису процесів, вимог і взагалі подання інформації (як є, як буває, як треба, як не треба, як може бути… :)

Це якщо у вас виникнуть питання – «А як ви описуєте вимоги?» або «А за допомогою якого інструменту ви пишете»?

Тобто важливіше не в тому, яким інструментом, а в тому щоб докопатися до суті.

Історія (перша) про банківську комісію:

Як було:

За проведення кожного платежу від клієнтів банк стягував 2 грн.

В системі BAS для документу Надходження безготівкових коштів було дописано додаткову проводку, яка списувала на витрати цю комісію.

До цього також розробили обробку, щоб вирівнювати рахунок 361, тому що продаж Кт361 на суму (Х) грн, а надходження грошей Дт361 на суму (Х-2)грн.

Якось в черговий раз щось пішло не так, треба було виправити баги і навчити нового бухгалтера.

Я зрозумів, що це не зовсім ергономічний процес і задумався як його оптимізувати, зявилася ідея із іншим способом стягнення комісії – не за кожен платіж, а узагальнено за підсумками місяця.

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

В системі BAS ми з розробником ввели параметри для деактивації тієї дописаної проводки в потрібний момент.

Історія (друга) про розрахунки в валюті

Як було:

Для розрахунків із іноземним постачальником придумали і розробили цілий процес розрахунку, застосування валютного курсу і контролю за гривневою сумою.

В системі BAS для цього змінили логіку роботи документів Списання безготівкових коштів: додали поле для відображення валютного курсу, кнопки для його розрахунку, змінили алгоритми відображення проводок…

Все для того, щоб бухгалтер відкривав кожен документ, у ньому розраховував курс, по якому має розраховуватись гривнева сума списання з рахунку 632. Ще до переходу в систему BAS, з давніх давен, в цій компанії так велося. Облік вели за середньозваженим курсом.

Все це з горем пополам якось криво-косо працювало для платежів по одному замовленню, але платежу по двох замовленнях приходилось ділити на два документи, жалілися що незручно.

Просили відокремити в документі курси по різних замовленнях.

Було очевидно, що це незручно як у застосуванні, так і у підтримці (постійні звернення щодо виправлення помилок від користувачів).

У мене був певний досвід із валютними платежами і мені здавалося, що стандартний механізм в цих документах працює ефективніше.

Я змоделював кейси в стандартному функціоналі і пересвідчився у цьому.

В чому суть стандартного механізму:

- при списанні валютної суми гривнева ділиться пропорційно

валютній. Якщо списується вся валюта, то списуються всі гривні. Просто та надійно.

Це суттєво оптимальніше, адже не потребує роботи з кожним платежем, відсутні помилки обробки даних користувачем, а також не зявляться гривневі сальдо (із нульовим валютним сальдо) на рахунку 632 через ланцюги перерахунків (розрахунок курсу із суми – розрахунок суми із курсу).

Я все детально розписав і запропонував відмовитись від цих «костилів» і повернутися до стандартного фунціоналу.