ERP-системы *

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

Импортозамещение в ИТ, локальный российский тренд последних лет. На протяжении последнего года — это слово многократно звучало из каждого “утюга”. Причины — крупные западные вендоры, в силу геополитических причин, ушли из России. Это болезненно отразилось на промышленности и крупных компаниях, они потеряли доступ к покупке лицензий, поддержке, обновлениям ect. Больно терять ERP, DSS, цифровая трансформация промышленности и бизнеса в России, очевидно, замедлится. Распространено мнение, что опыт цифровой трансформации и автоматизации, а также разработка систем управления процессами предприятий начались в России в девяностые, а 1С, Галактика и Монолит выросли на ровном месте, но это не совсем так...

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

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

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

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

В связи с обострением вопросов импортозамещения многие задумываются о переходе на системы, позволяющие заменить зарубежные аналоги, или уже его начали. Мы решили поделиться с вами 7-летним опытом установки и эксплуатации системы Linux + PostgresSQL + «1C» на 300 онлайн-пользователей.

Авторы статьи:

Стрижевский Александр – начальник ИТ-отдела АО «123 авиаремонтный завод»* («123 АРЗ»)

Малышев Дмитрий – разработчик в ВЦ «Раздолье», «1С»-эксперт по технологическим вопросам

 *АО «123 АРЗ» - одно из ведущих предприятий по ремонту и техническому обслуживанию транспортных самолётов военной и гражданской авиации России. Широкий спектр услуг с применением передовых технологий, тесное сотрудничество с разработчиками авиационной техники, адекватность потребительскому спросу и высокое качество ремонта – главные приоритеты предоставляемых услуг. Нам доверяют ремонт авиационной техники не только российские, но и зарубежные авиакомпании, расположенные на трёх континентах.

Начнём с опыта установки и эксплуатации системы Linux.

Сегодня использование альтернатив Microsoft не имеет каких-то нерешаемых проблем или серьёзных рисков. Комбинация Linux + PostgresSQL является хорошей платформой для информационной системы на базе программных продуктов «1С», но так было не всегда.

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

В компаниях то же самое: корпоративы не делают коллег сплочёнными и дружными, пылятся корпоративные библиотеки, красивые и удобные офисы не прокачивают профессиональные навыки, современные ПК не пишут хороший код (к счастью, и плохой тоже), CRM и ERP не разгоняют прибыль до первой космической, и даже самые навороченные боты и IVR не способны идеально обслужить клиентов. Нужны люди — с целями, волей и мозгами. Чувство юмора и здравый смысл — опциональны :-) 

Достаточно часто при проектировании схемы БД возникает задача сохранить по основной сущности некоторый набор простых второстепенных данных.

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

Во всех этих случаях мы заранее понимаем, что список этот меняется редко и ни индексировать эти данные, ни искать по ним, ни извлекать отдельно от основной сущности (встречи, сообщения или документа), мы не захотим.

Давайте посмотрим, какие варианты хранения таких данных мы можем использовать в PostgreSQL, и какой из них окажется в разы более эффективным.

ERP система – гибкое решение для автоматизации сложных, многоступенчатых бизнес-процессов. Это универсальная единая информационная система, целью внедрения которой является оптимизация бизнес-процессов компании и получение конкурентного преимущества. Так как проекты по внедрению ERP требуют больших временных и денежных ресурсов, важно точно определить цели еще до старта проекта. Такой целью могут быть, например, улучшение показателя окупаемости инвестиций. 

Хабр, привет! Меня зовут Вера Кокотова, я тимлид группы технической архитектуры и разработки в направлении 1С. В посте хочу рассказать, как мы в проектах управляем жизненным циклом приложений от инфраструктуры до развернутого в web сервиса с помощью подхода Infrastructure as Code. 

До автоматизации процессов разворачивания мы тратили до 40 часов на то, чтобы поднять сервер со сборочной линией, и 1-2 дня на сам стенд разработки и автотесты. Сейчас – 40 минут и довольные инженеры, которые смогли почти полностью уйти от рутины системного администрирования и сосредоточиться на развитии практик в рамках группы.

Как мы пришли к такому happy end и что у системы под капотом – читайте после ката.

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

Уже давно в этих встречах ничего особенного не было. Вероятно, потому, что я для себя и команды сознательно выбрал рынок среднего бизнеса, и появилась ожидаемая повторяемость. Но там люди как-то поживее, чем в Больших и Важных Корпорациях. И, в большинстве случаев, удаётся встретиться с собственником – это кратчайший путь к пониманию духа компании.

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

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

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

Итак, чего они там вытворяют.

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

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

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

1. Есть как минимум два распространенных способа выбора поставщика: запрос котировок и запрос предложений. Последний часто называют тендером. Отличие их в том, что определение поставщика в первом случае происходит исключительно по цене, а во втором — по более широкому перечню критериев, объявленных публично или скрытых от участников.

Особенности конкурентных процедур

Практика конкурентных процедур за последние десятилетия была принята во всех организациях, имеющих то или иное отношение к бюджетному финансированию (речь о нормах федеральных законов с условным обозначением 44-ФЗ, 223-ФЗ и др.). Для неё характерно широкое применение строгих форм процедур — так называемых «торгов», если говорить терминами Гражданского кодекса РФ: у заказчика возникает обязательство заключить договор с победителем торгов. В коммерческом секторе ту же процедуру называют иначе — «тендер», «запрос предложений» и др.

Выделим основные характеристики процедуры, устоявшиеся в российском коммерческом секторе:

Есть такая штука — товарная дистрибуция. Так называют движение продукции от производителя до каждого дома. Этот процесс возник тысячи лет назад. А вот за последние 30 лет дистрибуция сильно поменялась. Расскажу что конкретно произошло и какую роль в этом сыграли технологии.

Читатели постарше могут помнить такую профессию — «торговый представитель». Эти ребята на служебных Ford Focus гоняли по районам, заходили в магазинчики и оформляли заказы на поставку сникерсов и стирального порошка. Раньше на людях — торговых представителях, мерчандайзерах и супервайзерах строились практически все процессы. Кое-где эти профессии еще сохранились, но они перестали быть массовыми. Почти все компании сегодня продают с применением ИТ.

Хотелось бы представить на суд местного сообщества недавно созданную облачную веб платформу разработанную бывшим 1с-овцем освоившим java, js, ts, react.

Интерфейсы TypeScript(*.d.ts файлы) генерируются на лету. Они актуальны и доступны в коде даже без сохранения конфигурации.

Главная фишка - есть возможность писать обработчики событий на языке TypeScript и sql код на триггеры при записи объектов. Редактор кода тоже онлайн и реализован на базе monaco-editor. В нем типизируется все: структура и типы метаданных, данные и элементы формы, события обработчиков.

Год назад я рассказал на Хабре, как мы сделали заказное мобильное приложение для коллекторов. Речь и тогда и сейчас только о технологиях, не о этике и практике взысканий. Сегодня эта разработка развилась в полноценную мобильную CRM с голосовым роботом (робот — это теперь и отдельное ПО). И что важно, приложение не только полностью цифровизирует работу выездного коллектора, но и обладает встроенной защитой должников и непричастных лиц в соответствии с законом №230-ФЗ.

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

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

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

Приветствую, коллеги.

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

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

Итак, представим, что у нас имеется некоторое количество приложений, которые изначально “не обучены” отдавать аналитику в режиме реального времени. Задача заключается в том, чтобы построить систему мониторинга бизнес-показателей с минимальным вмешательством в эти системы.

Существует множество способов решить эту задачу, и как водится, все они обладают своими достоинствами и недостатками. Основное достоинство описываемого способа заключается в очень простой реализации на стороне приложения (с которого есть необходимость получать аналитику). Но если бы мы сейчас разрабатывали все те приложения, которые нужно “научить” делиться аналитикой, то мы бы, наверное, их подружили с брокером сообщений типа Kafka или Rabbit, а внедрять в уже существующие приложения работу с брокером сообщений (особенно, если брокеры очередей сообщений не развернуты в компании) значительно сложнее, чем просто научить приложения писать свои показатели в лог.

Итак, рассмотрим подробно, как устроена предлагаемая система:

В основе системы лежат события, которые генерируют приложения. События сохраняются в лог (stdout, файл,..). Обработчик (сборщик) логов (в режиме реального времени) распознает в логах события приложений и отправляет их в хранилище (БД).

Автоматизация и цифровизация бизнеса сейчас очень популярные понятия. Многие понимают, что им это обязательно надо, это модно, это здорово, особенно важна автоматизация для производственных компаний и маркетплейсов, где масса информации, которую вручную без специальных программ практически невозможно обрабатывать. Но, начиная процесс автоматизации, все руководители сталкиваются с одним и тем же: пока у них хаос и сумбур в так называемой нормативно-справочной информации (НСИ), трудно двигаться дальше, переходить на «цифровые рельсы», которые повезут твой ̶п̶о̶е̶з̶д̶ бизнес к станции увеличения прибыли.

Оптимизация НСИ – это база для внедрения ERP-системы, для цифровой трансформации любой компании. Это надо чётко уяснить и постараться навести порядок в своих данных НСИ.

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

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

Это было в 2016 году. У одного крупнейшего в России ритейлера стояла глобальная задача перейти на новую ERP-систему. Поскольку основные усилия были сосредоточены на перестроении бизнес-процессов, заказчик решил отдать задачи по ИТ на аутсорс и обратился к нам. Мы предложили ему комплексную услугу по аутсорсингу и аренде инфраструктуры, куда входили СХД, СРК, СУБД, виртуализация, физические серверы, сетевая инфраструктура.

После того, как завершился начальный этап внедрения продуктива, выявились ряд проблем, которые потенциально могли влиять на производительность и отказоустойчивость созданной системы. И таким «узким местом» стала виртуализация. О том, почему мы решили уйти от enterprise-решения на Open Source, а также почему этот опыт в текущих реалиях может быть полезным, мы и собираемся рассказать в сегодняшнем посте.