1С *

SLA (Service Level Agreement) — это соглашение об уровне услуг, документ, который четко определяет, кто, что и в какие сроки должен делать.

SLA (Service Level Agreement) — это не просто очередная бюрократическая бумажка, а свод правил, который спасает проекты от хаоса.  Если представить проект внедрения 1С как футбольный матч, то SLA — это правила игры. Если у одной команды — мяч, а у другой — шайба, игра превращается в хаотичную драку. SLA как раз и нужен, чтобы все играли по одним правилам.

SLA нужен, чтобы:

· Минимизировать недопонимание между заказчиком и подрядчиком
· Зафиксировать зоны ответственности
· Избежать ситуаций, когда одна сторона ждет «чуда», а другая — оплаты за «непредусмотренные работы»

Но почему SLA нужен именно в проектах внедрения 1С?

Внедрение 1С — это не просто установка программы. Это сложный процесс, который включает:

· Анализ бизнес-процессов
· Настройку и доработку конфигураций
· Тестирование и исправление ошибок
· Обучение пользователей

Без четкого SLA проект рискует превратиться в бесконечный цикл:

Заказчик: «Мы думали, вы сами все сделаете!»
Подрядчик: «А мы думали, вы предоставите данные и выделите ответственных!»

SLA помогает:

· Определить этапы и сроки
· Зафиксировать, какие ресурсы (люди, данные, доступы) нужны от заказчика и в какие сроки
· Прописать KPI и критерии успешного внедрения.

Но очень важно в SLA зафиксировать обязанности не только подрядчика, но и заказчика.

Представьте, что вы наняли строителей для ремонта, но не предоставили им ключи от квартиры. Как они будут работать? Точно так же и в проектах внедрения 1С: если заказчик не выделяет ответственных, не предоставляет данные или затягивает согласование, проект встает.

Доброго времени суток, меня зовут Тимур. Я являюсь разработчиком на 1С платформе и так получилось что я разбираюсь в Web технологиях, моим любимым языком является PHP, и я подумал почему бы не сделать программное средство для администрирования 1С через web.

Администрировать 1С сервер можно через командную строку при помощи компоненты RAC которая предоставляет только терминальный интерфейс, что немного не удобно.

О компоненте я задумался чтобы самому администрировать 1С немного удобнее, а через Web интерфейс было вообще идеально. И вот что получилось...

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

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

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

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

При переезде 1С с Windows-платформ пользователи сталкиваются с тем, что привычный подход "одна база - один пользователь" реализовать как-то не очень получается. В мануалах, которые можно нагуглить, предлагается либо соединяться с СУБД от имени пользователя postgres, либо создать нового пользователя и выдать ему права SUPERUSER, что с точки зрения изоляции баз друг от друга выглядит как-то "не очень".

Для чего используют кластеризацию серверов СУБД? Вопрос не совсем праздный, особенно для крупных компаний. Если с кластеризацией/масштабированием серверов приложений, терминалов, web-серверов и т. д. все понятно и прозрачно, то вот с СУБД не всё так просто. Особенно для 1С систем.

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

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

Привет! Меня зовут Петр, я начал свой путь 1С разработчика в 2021 году, и за почти 5 лет стажа успел поработать в самых разных компаниях: с крупным бизнесом, корпорациями и даже государственными структурами. Все большие проекты, на которые меня выводили, были похожи друг на друга. Большая команда, 3–4 контура, автотестирование и т.д. всегда масштабно! Но к моему удивлению даже на таких больших проектах зачастую халатно относились к защите данных! Но были проекты, на которых данные клиента были защищены на очень достойном уровне.

Из своего опыта и опыта моих коллег, я пришел к такому тезису: если не защищать данные — могут поставить под угрозу бизнес и пользователей.

С 1 сентября 2025 года в силу вступают важные изменения в законодательстве России о персональных данных, касающиеся обезличивания (анонимизации) персональной информации. Цель — установить чёткие правила обезличивания и дать бизнесу и государству новые возможности для безопасного использования больших данных и технологий искусственного интеллекта.

Уже давно стали обыденными внедрения решений на платформе 1С:Предприятие на тысячу одновременных пользователей. Есть внедрения и более масштабные. И масштаб внедрений растёт. Поэтому мы решили убедиться, что платформа выдержит нагрузку нашего самого востребованного на крупных внедрениях решения 1C:ERP на 30 000 одновременно работающих пользователях.

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

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

Внедрения ERP‑систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко‑дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP‑систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4].

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

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

Материал посвящен разработке web‑приложения на новой технологии от 1С — 1С:Элемент. Мы на этой технологии реализовали приложение «Книжный клуб» в тесном взаимодействии с заказчиком, опытом использования данной технологии и хочу поделиться.

Выступаю я с позиции разработчика из сети 1С‑Франчайзи, поэтому смотрю на вещи «со своей колокольни» и опыт конечно же тоже специфический. В проекте принимаю участие как аналитик и руководитель проекта со стороны исполнителя.

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

Экосистема продуктов 1С содержит много различных полезных инструментов разработки. Одним из них является 1C:EDT (1C:Enterprise Development Tools) — расширяемая среда разработки прикладных решений, созданная на основе свободной интегрированной среды разработки модульных кроссплатформенных приложений Eclipse.

1C:EDT поддерживает ключевые принципы создания прикладных решений на платформе «1С:Предприятие 8» и содержит большое количество инструментов автоматизации разработки, делающих работу программиста более быстрой и комфортной, а также позволяет расширять функциональность инструментов разработки с помощью технологии плагинов.

В этой статье мы поговорим о том, как интегрировать 1С:EDT с системой контроля версий Git для того, чтобы сделать разработку более эффективной.

Российское законодательство обязывает работодателей соблюдать строгие правила при работе с персональными данными сотрудников. HR-менеджеры, руководители отделов и специалисты по безопасности часто задаются вопросом: нужно ли получать отдельное согласие от сотрудника на обработку его персональных данных в рамках трудовых отношений? Проще говоря, обязаны ли мы при каждой ситуации брать у работника письменное согласие, или закон допускает обработку данных и без него? Рассмотрим это на основе российского Федерального закона № 152-ФЗ «О персональных данных» и разъяснений Роскомнадзора, простым языком.

Многие до сих пор воспринимают IT-индустрию как пространство для молодых: стартапы, хакатоны, agile-команды и шумные open space. В голове автоматически возникает образ 20–30-летнего разработчика в худи. А если добавить, что речь о программировании на 1С, — так вообще большинство подумает о крепком мужчине предпенсионного возраста с двадцатью годами стажа в одной системе.

Но бывают исключения, которые ломают шаблоны. И об одном таком исключении я расскажу сегодня.

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

Согласно своду по управлению знаниями PMBoK существует 4-е ключевые плана, характеризующие любой проект, в том числе внедрение ERP-систем: график проекта, ресурсный план, план затрат и закупок. В литературе обычно описывают только построение плана-графика проекта с использованием методов критического пути и цепи, однако взаимосвязь с ресурсным планом и прочими планами обычно опускают. В работе [1] сделана попытка одновременного построения первых трех планов в виду их корреляции, способ базируется на бенчмаркинге этапов проекта и оценщике разработок. Однако вопрос оптимизации построенного ресурсного плана обсуждается лишь вскользь.

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

Создание проектного плана может вестись согласно двум классическим способам, описанным в своде знаний PMBoK [2]: критический путь и критическая цепь. Метод критического пути предполагает декомпозицию всех проектных задач, выстраивание их логической последовательности и взаимосвязей, выставление предполагаемых продолжительностей и расчет одноименного пути. Способ не оперирует человеческими ресурсами, поэтому не всегда понятно на основе каких правил рассчитываются продолжительности задач, ведь они зависят от числа ресурсов. Следующий способ, метод критического пути, расширяет предыдущий, вводя три вида «буферов» (ресурсные, поддерживающие и проектные), для сглаживания неопределенностей и возможных задержек. Здесь сроки задач и наличие буферов устанавливаются согласно доступности человеческих ресурсов, после чего строится все тот же критический путь. Применение обоих методов на практике видится крайне трудозатратным в особенности при часто изменяющихся вводных. Поэтому в качестве базиса построения ресурсного плана воспользуемся методом, основанном на бенчмаркинге фаз ERP-проекта [3].

В госкомпаниях ежедневно работают с сотнями договоров, соглашений и внутренних регламентов. Такие объемы документооборота требуют автоматизации процессов согласования, контроля и архивирования. В этой статье расскажу, как Корпорация развития Московской области (КРМО) переехала на СЭД на базе BPM-платформы с автоматическими маршрутами согласования, контролем физических документов и интеграцией электронной подписи.

Привет, Хабр! Меня зовут Анна Блюмина, я консультант-эксперт департамента 1C ‭«КОРУС Консалтинг».

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

В данной статье я хочу поделится своим видением обоих профессий, сравнить их и дать свою субъективную оценку, а так же рассказать историю ИТ в общих чертах за последние 5 лет, как ИТ пузырь начал раздуваться и как он в конце концов лопнул.

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