Показ дописів із міткою CMS. Показати всі дописи
Показ дописів із міткою CMS. Показати всі дописи

пʼятниця, 24 квітня 2026 р.

Інтернет-магазин у K2 ERP: каталог, замовлення, CRM і склад


 

Більшість компаній, які запускають інтернет-магазин, дуже швидко стикаються з однією й тією самою проблемою: сайт живе окремо, ERP живе окремо, CRM живе окремо, складський облік живе окремо, а між ними постійно потрібно щось синхронізувати, переносити, звіряти, виправляти й контролювати.

І от замість розвитку продажів бізнес отримує нову корпоративну гру: «Знайди, де загубилося замовлення». Участь беруть менеджер, бухгалтер, склад, програміст, інтегратор і трохи нервова система керівника.

У результаті компанія витрачає ресурси не на продажі, а на боротьбу з дублями, помилками, затримками, нескінченними інтеграціями та питанням: «А чому на сайті одне, а в ERP інше?»

Інтернет-магазин у K2 ERP працює за іншим принципом. Це не сторонній сайт, який «прикручений» до облікової системи скотчем, API й молитвою. Це повноцінна частина єдиної ERP-екосистеми, де товари, клієнти, замовлення, ціни, залишки, характеристики, файли, CRM, управлінський облік, багатомовність і користувацькі додатки працюють в одному інформаційному полі.

Саме в цьому і є його головна сила.

Єдина структура замість дублювання даних

У класичному підході інтернет-магазин часто має власну базу товарів, власні категорії, власні описи, власні переклади, власні картки клієнтів, власні замовлення. Потім усе це потрібно синхронізувати з ERP.

А будь-яка синхронізація — це як переїзд офісу: начебто все перевезли, але десь зник стілець, папка з договорами і впевненість у завтрашньому дні.

В K2 ERP інтернет-магазин використовує ті структури, які вже є в системі.

Номенклатура вже заведена. Категорії вже існують. Характеристики вже описані. Файли, зображення, документи, сертифікати, інструкції вже можуть бути прив’язані до товарів. Клієнти вже ведуться в системі. Документи продажу вже налаштовані. CRM уже працює. Управлінський облік уже збирає потрібні дані. Багатомовні описи вже можуть бути частиною картки номенклатури.

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

Це не дублювання бізнесу в онлайні. Це онлайн-вітрина вже працюючого бізнесу.

Замовлення в реальному часі — без ручного перенесення

Коли клієнт оформлює замовлення в інтернет-магазині, воно одразу потрапляє в ERP-систему. Не через годину. Не після нічного обміну. Не після того, як менеджер вручну перенесе дані з адмінки сайту, попутно випивши каву, відповівши на три дзвінки й випадково переплутавши артикул.

Замовлення одразу стає частиною бізнес-процесу.

Менеджер бачить його в системі. CRM може автоматично створити або оновити контакт із клієнтом. Склад бачить потребу в резервуванні або відвантаженні. Управлінський облік отримує дані для аналізу. Керівництво бачить реальну картину продажів.

Це особливо важливо для компаній, де швидкість реакції напряму впливає на продаж. Клієнт не чекає, менеджер не губить заявку, склад не працює «всліпу», а бізнес не втрачає гроші через затримки між системами.

Реальний час — це коли замовлення вже в роботі, а не десь “має підтягнутися після синхронізації”.

CRM підключена одразу

Інтернет-магазин у K2 ERP не просто приймає замовлення. Він одразу пов’язаний із клієнтською базою та CRM.

Це означає, що кожна дія покупця може ставати частиною історії взаємодії з ним: реєстрація, замовлення, повторні покупки, звернення, персональні умови, історія оплат, документи, комунікації.

Менеджер працює не з «новою заявкою з сайту», яка загадково з’явилася в пошті о 23:47, а з повноцінним клієнтом у CRM.

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

Це перетворює інтернет-магазин із простої онлайн-вітрини на справжній канал продажів, інтегрований у загальну систему роботи з клієнтами.

І найприємніше: CRM не треба благати «підтягни дані з сайту». Вона вже в курсі.

Управлінський облік без додаткових інтеграцій

Окремий інтернет-магазин часто дає лише частину картини: кількість замовлень, суми, базову аналітику. Але для управління бізнесом цього мало.

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

Коли інтернет-магазин є частиною K2 ERP, дані з онлайн-продажів одразу потрапляють у контур управлінського обліку. Не потрібно будувати додаткові обміни, імпорти, звіти й перевірки коректності.

Бізнес бачить не просто “скільки продали на сайті”, а як ці продажі впливають на всю компанію.

Тобто керівник отримує не набір красивих цифр для настрою, а реальну управлінську інформацію для рішень. І це набагато корисніше, ніж графік “у нас сьогодні було багато кліків”.

Реалізація інтернет-магазину стає простішою

Одна з найбільших переваг такого підходу — швидкість і логічність впровадження.

Коли компанія створює інтернет-магазин окремо від ERP, потрібно заново проектувати багато речей: структуру товарів, довідники, картки номенклатури, логіку цін, складські залишки, документи, клієнтів, статуси замовлень, ролі користувачів, переклади, інтеграції з обліком.

Іноді здається, що будується не інтернет-магазин, а маленька держава зі своїми законами, паспортною системою, митницею і конфліктом з ERP на кордоні.

У K2 ERP більшість цього вже є.

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

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

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

Опис товару один — і для ERP, і для інтернет-магазину

Окрема сильна перевага K2 ERP — нерозривність описів номенклатури та описів товарів в інтернет-магазині.

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

Це момент, коли відповідальний співробітник відкриває десять вкладок і тихо мріє про відпустку без Wi-Fi.

У K2 ERP опис товару може бути єдиним джерелом правди.

Оновили інформацію про номенклатуру — вона доступна і в ERP-модулях, і в інтернет-магазині. Додали характеристику — її можна використати в картці товару. Прикріпили файл — він може бути доступний там, де це потрібно. Оновили опис — він не розходиться між системами.

Один опис. Одна логіка. Одна система. Менше хаосу. Більше продажів.

Це економить час, зменшує кількість помилок і підвищує якість інформації для клієнта.

Багатомовність без подвійної роботи

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

У традиційному підході переклади часто живуть окремо: в ERP — одна інформація, на сайті — інша, у маркетингових матеріалах — третя. Через це з’являються розбіжності, застарілі тексти, неправильні назви товарів або неповні описи різними мовами.

А потім клієнт читає англійську версію товару, український менеджер дивиться в ERP, бухгалтер бачить ще одну назву в документі — і всі дружно намагаються зрозуміти, чи це один і той самий товар, чи вже міжнародний детектив.

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

І навпаки: робота з мовними версіями інтернет-магазину не відривається від ERP-логіки. Компанія не підтримує два окремі набори перекладів, а працює з єдиною структурою даних.

Це особливо важливо для B2B-компаній, експортерів, виробників, дистриб’юторів і бізнесів із широким асортиментом. Коли товарів багато, ручне дублювання перекладів швидко перетворюється на дорогий і неконтрольований процес.

У K2 ERP багатомовна номенклатура стає частиною єдиної системи: оновили опис українською, додали англійську версію, змінили технічну характеристику іншою мовою — і ця інформація може бути використана там, де вона потрібна: в ERP, в інтернет-магазині, у кабінеті клієнта, у документах або в інших модулях.

Багатомовність перестає бути ручною роботою “скопіюй-встав-перевір-помолись”. Вона стає нормальною частиною системи.

Характеристики, файли та документи працюють всюди

У K2 ERP механізм характеристик, файлів і пов’язаних даних закладений на рівні системи. І це надзвичайно важливо для інтернет-магазину.

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

І головне — ці дані не потрібно створювати окремо для сайту.

Те, що вже використовується всередині ERP, може автоматично використовуватися і в інтернет-магазині. Це дає єдину логіку роботи з товаром: від внутрішнього обліку до зовнішньої презентації клієнту.

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

Тобто замість «уточнюйте у менеджера» клієнт бачить характеристики, файли, документи й опис. А менеджер у цей момент може займатися продажами, а не надсилати один і той самий PDF двадцятий раз за день.

Мобільні та десктопні додатки працюють у тій самій логіці

Сучасний бізнес не обмежується роботою тільки в браузері. Менеджери, керівники, торгові представники, складські працівники, сервісні фахівці та клієнти можуть використовувати різні інтерфейси: веб, мобільні додатки під Android та iOS, а також десктопний додаток.

Перевага K2 ERP у тому, що функціональність не потрібно створювати окремо для кожного каналу з нуля. Якщо бізнес-логіка, документи, довідники, характеристики, файли, статуси, права доступу або процеси вже реалізовані в системі, вони можуть використовуватися різними інтерфейсами.

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

Для бізнесу це величезна перевага. Не потрібно окремо підтримувати різні логіки для сайту, мобільного застосунку, внутрішньої ERP та робочого місця менеджера. Усі вони спираються на єдину систему.

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

Керівник бачить дані в зручному інтерфейсі. Менеджер працює із замовленням у CRM. Клієнт оформлює покупку в інтернет-магазині. Співробітник може взаємодіяти із системою через мобільний або десктопний додаток.

Але всі вони працюють не з різними копіями даних, а з єдиною ERP-платформою.

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

Зміни у функціоналі автоматично відображаються всюди

Ще одна важлива перевага єдиної ERP-архітектури — системність змін.

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

Якщо інтернет-магазин існує окремо, кожну зміну потрібно окремо реалізовувати або синхронізувати між системами. І знову починається знайома історія: «на сайті вже змінили, в ERP ще ні, в мобільному додатку частково, а в Excel у директора взагалі своя версія правди».

У K2 ERP зміни в загальній логіці системи можуть одразу впливати на всі пов’язані модулі, включно з інтернет-магазином, мобільними додатками, десктопним додатком, CRM і управлінським обліком.

Це робить розвиток системи набагато природнішим: бізнес змінює правила в одному середовищі, а не намагається підтримувати однакову поведінку в кількох різних продуктах.

Менше дублювання. Менше інтеграцій. Менше ризиків. Більше керованості.

Кабінет клієнта як частина ERP-процесу

Особистий кабінет клієнта в інтернет-магазині K2 ERP може бути не просто сторінкою з історією замовлень. Він може стати зручним вікном клієнта в бізнес-процеси компанії.

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

А для компанії це означає менше ручних запитів до менеджерів, менше уточнень телефоном, менше хаосу в комунікації.

Бо якщо клієнт сам бачить статус замовлення, документ або потрібний файл, йому не потрібно телефонувати з питанням: «А що там моє замовлення?» А менеджеру не потрібно відповідати: «Зараз уточню», хоча він уточнює це вже в одинадцятий раз за день.

Клієнт отримує прозорість і зручність. Бізнес отримує автоматизацію й контроль.

Інтернет-магазин у K2 ERP — це не сайт. Це продовження бізнес-системи

Головна цінність інтернет-магазину в K2 ERP полягає не тільки в тому, що компанія отримує онлайн-продажі. Головна цінність у тому, що ці продажі одразу вбудовані в операційну модель бізнесу.

Товар не дублюється.
Клієнт не губиться.
Замовлення не переноситься вручну.
CRM не живе окремо.
Управлінський облік не чекає імпорту.
Описи, характеристики й файли не розходяться між системами.
Багатомовність не підтримується вручну в кількох місцях.
Мобільні, десктопні та веб-інтерфейси працюють у єдиній логіці.
Будь-яка зміна не потребує нескінченного повторення в різних системах.

Усе працює як єдиний механізм.

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

Для клієнта — зручний інтернет-магазин, актуальна інформація, швидке оформлення замовлення, правильна мовна версія, прозорий кабінет і якісна взаємодія.

Для бізнесу — сильний цифровий канал продажів, який не відривається від ERP, а працює разом із нею.

Інтернет-магазин у K2 ERP — це коли онлайн-продажі не створюють новий хаос, а підсилюють уже налагоджену систему управління компанією.

І, що важливо, без ритуальних танців навколо синхронізації.


Оригінал статті: https://erp.kyiv.ua/internet-magazyn-u-k2-erp-koly-onlajn-prodazhi-stayut-chastynoyu-yedynoyi-systemy-a-ne-okremym-golovnym-bolem/

CMS у K2 ERP: як сайт передає заявки в CRM і запускає процеси



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

Клієнт залишив заявку — її треба десь побачити.
Заповнив форму — її треба вручну перенести в CRM.
Подзвонив із сайту — менеджер записав щось у блокнот.
Попросив комерційну пропозицію — дані знову копіюються вручну.
Змінилася інформація в ERP — на сайті її ще хтось має оновити.

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

Але коли CMS знаходиться всередині ERP-системи, усе працює інакше.

Що таке CMS у контексті ERP

CMS — це система керування контентом сайту: сторінками, текстами, меню, блоками, банерами, новинами, формами, файлами, SEO-описами, посадковими сторінками та іншими елементами, які бачить користувач.

Зазвичай CMS — це окрема система. Вона відповідає за сайт, а ERP — за облік, замовлення, клієнтів, склад, фінанси, документи, CRM та бізнес-процеси.

У K2 ERP CMS може бути частиною єдиної бізнес-платформи. І це принципово змінює роль сайту.

Сайт перестає бути просто набором сторінок. Він стає зовнішнім інтерфейсом ERP-системи — точкою входу для клієнтів, партнерів, заявок, звернень, форм, замовлень, документів і комунікацій.

Іншими словами, сайт починає не просто “показувати інформацію”, а працювати на бізнес-процеси.

Сайт компанії як частина єдиної системи

За допомогою CMS у K2 ERP можна створити повноцінний сайт компанії: корпоративний портал, промосайт, каталог, інформаційний ресурс, сайт послуг або B2B-платформу.

Але головна перевага не лише в тому, що сторінки можна редагувати. Головна перевага в тому, що сайт одразу пов’язаний із внутрішніми процесами компанії.

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

Тобто користувач заходить на сайт, а бізнес одразу отримує не просто “відвідувача”, а потенційного клієнта, заявку, контакт, звернення або початок бізнес-процесу.

Сайт у такій архітектурі — це не окремий острів. Це вхідні двері в ERP.

Контакти, CRM та IP-телефонія в одному контурі

Один із найважливіших елементів корпоративного сайту — контакти. Але в сучасному бізнесі контакти — це не просто номер телефону й email на сторінці.

Коли сайт інтегрований із ERP, контактна взаємодія може одразу переходити в CRM і пов’язані інструменти комунікації.

Наприклад, клієнт натискає кнопку “Зателефонувати”, залишає номер, замовляє дзвінок або звертається через форму. У класичній схемі ці дані часто потрапляють на пошту, у месенджер або взагалі губляться між відповідальними.

У K2 ERP така взаємодія може бути одразу пов’язана з CRM-модулем, клієнтською базою та IP-телефонією.

Це означає, що звернення з сайту може автоматично створити контакт, лід, задачу для менеджера або запис у CRM. Дзвінок може бути пов’язаний з карткою клієнта. Історія комунікації не губиться. Менеджер бачить, хто звернувся, з якої сторінки, з яким запитом і що з цим потрібно зробити.

І тут зникає класична проблема: “Хтось дзвонив із сайту, але хто саме, що хотів і кому передали — вже ніхто не пам’ятає”.

Кожен контакт із сайту стає частиною контрольованого процесу продажу або сервісу.

Динамічні форми з ERP прямо на сайті

Одна з найсильніших можливостей CMS всередині ERP — це виведення на сайт динамічних форм, які пов’язані з даними та процесами ERP-системи.

Це можуть бути не просто стандартні форми “Ім’я, телефон, коментар”. ERP дає можливість створювати значно розумніші сценарії збору інформації.

Наприклад, на сайт можна вивести форми для:

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

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

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

Форма на сайті стає не просто HTML-блоком. Вона стає частиною ERP-процесу.

Зібрана інформація одразу потрапляє в ERP

Найцінніше в такому підході — не сама форма, а те, що відбувається після її заповнення.

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

І все це вручну.

А ручна робота — це завжди ризик: щось забули, щось скопіювали не туди, щось не передали, щось обробили із запізненням.

У CMS, що працює всередині K2 ERP, заповнена форма може одразу створити потрібний об’єкт у системі: лід, контакт, заявку, звернення, задачу, документ, замовлення, сервісний кейс або внутрішній бізнес-процес.

Клієнт натиснув “Надіслати” — і ERP уже працює.

Дані не треба переносити. Вони вже в системі.

Автоматична обробка заявок і бізнес-процеси

Коли інформація потрапляє безпосередньо в ERP, її можна не просто зберігати, а обробляти за правилами бізнесу.

Наприклад:

заявка з певного регіону автоматично потрапляє відповідальному менеджеру;
звернення з темою “сервіс” створює сервісну задачу;
запит комерційної пропозиції запускає процес підготовки КП;
партнерська анкета йде на перевірку;
форма з технічними параметрами створює задачу для інженера;
звернення VIP-клієнта отримує вищий пріоритет;
після заявки клієнту автоматично надсилається підтвердження;
керівник бачить статуси обробки звернень у звітах.

Це вже не просто сайт. Це автоматизований канал входу інформації в компанію.

Сайт збирає дані, ERP їх приймає, CRM веде клієнта, відповідальні отримують задачі, керівництво бачить аналітику, а клієнт отримує швидшу реакцію.

І все це без “скинь мені цю заявку у вайбер, я потім внесу”.

CMS як інструмент для продажів, сервісу й маркетингу

CMS у ERP цікава не тільки для технічної зручності. Вона відкриває сильні можливості для продажів і маркетингу.

Компанія може створювати посадкові сторінки під окремі продукти, послуги, сегменти клієнтів або рекламні кампанії. Але ці сторінки можуть одразу бути пов’язані з CRM: джерело звернення, кампанія, форма, менеджер, статус обробки, подальші дії.

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

У класичному сайті маркетинг часто рахує “ліди”, а продажі потім кажуть: “Ну, ліди були так собі”.
В ERP-архітектурі можна дивитися глибше: від сторінки сайту до реального результату в продажах.

CMS стає не просто редактором контенту, а частиною воронки продажів.

Актуальні дані на сайті без дублювання

Коли CMS працює всередині ERP, на сайт можна виводити не тільки статичні тексти, а й актуальні дані з системи.

Це можуть бути:

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

Головна перевага — немає потреби вести однакову інформацію в різних місцях.

Оновили дані в ERP — сайт може показувати актуальну інформацію. Змінили опис, файл, характеристику або переклад — це не треба дублювати в окремій CMS. Компанія працює з єдиним джерелом правди.

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

Багатомовність як частина сайту й ERP

Для компаній, які працюють з різними ринками, багатомовність сайту дуже важлива. Але якщо переклади ведуться окремо в CMS, а номенклатура, документи й клієнтські дані — в ERP, швидко виникає плутанина.

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

Сайт, ERP і інтернет-магазин працюють з одними мовними даними, а не з трьома різними наборами перекладів.

Це особливо корисно для компаній з великим каталогом, експортом, B2B-продажами або кількома мовними версіями сайту.

Особисті кабінети, портали й закриті розділи

CMS всередині ERP також дає можливість створювати не тільки публічний сайт, а й закриті розділи для клієнтів, партнерів або співробітників.

Наприклад:

клієнтський кабінет;
партнерський портал;
портал дилерів;
сервісний кабінет;
кабінет постачальника;
внутрішній портал компанії;
розділ для документів;
особистий простір для заявок і звернень.

І знову головна перевага — ці кабінети можуть працювати не з окремою базою сайту, а з ERP-даними.

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

CMS стає не просто інструментом для публічних сторінок, а основою для цифрових порталів.

Чому це вигідно бізнесу

CMS у складі ERP — це цікаво не тому, що “ще один модуль є в системі”. Це цікаво тому, що сайт перестає бути окремим проєктом, який потрібно постійно з’єднувати з бізнесом.

Він уже з’єднаний.

Бізнес отримує:

єдину базу даних;
менше ручного перенесення інформації;
швидшу обробку заявок;
прямий зв’язок сайту з CRM;
контроль дзвінків і контактів через IP-телефонію;
динамічні форми з ERP;
автоматичне створення лідів, задач, документів або звернень;
актуальний контент без дублювання;
зв’язок маркетингу з реальними продажами;
менше помилок і більше керованості.

Інакше кажучи, CMS у ERP — це коли сайт не просто красиво виглядає, а реально працює в системі управління компанією.

Простий приклад: як це може працювати

Уявімо, що компанія продає складне обладнання або надає професійні послуги.

На сайті є сторінка продукту, опис, характеристики, файли, фото, сертифікати, кнопка “Отримати консультацію” і форма для запиту.

Клієнт заповнює форму: обирає тип обладнання, регіон, сферу застосування, додає коментар і прикріплює файл.

Далі все відбувається автоматично:

у CRM створюється лід або контакт;
заявка прив’язується до конкретної сторінки чи продукту;
відповідальний менеджер отримує задачу;
за потреби підключається технічний спеціаліст;
керівник бачить нове звернення у звітах;
клієнт отримує підтвердження;
подальші дії фіксуються в ERP.

І ніхто не копіює дані з пошти в таблицю.
Ніхто не питає: “А хто відповідає за цю заявку?”
Ніхто не шукає, з якої сторінки прийшов клієнт.

Система просто працює.

CMS у K2 ERP — це сайт, який думає разом із бізнесом

Головна цінність CMS у K2 ERP — у поєднанні контенту, даних і процесів.

Звичайна CMS допомагає створити сайт.
CMS у ERP допомагає створити цифровий канал взаємодії з бізнесом.

Це може бути корпоративний сайт, інтернет-магазин, клієнтський портал, партнерський кабінет, сервісна платформа або система збору заявок. Але в усіх випадках сайт не відірваний від обліку, CRM, телефонії, документів і процесів.

Клієнт бачить зручний сайт.
Менеджер бачить заявку в CRM.
ERP запускає потрібний процес.
Керівник бачить результат.
Бізнес не втрачає дані.

І саме в цьому сила такого підходу.

CMS у K2 ERP — це коли сайт компанії перестає бути просто “візиткою в інтернеті” й стає повноцінною частиною системи управління бізнесом.


Оригінал статті: https://erp.kyiv.ua/cms-u-k2-erp-sajt-kompaniyi-yakyj-ne-prosto-vysyt-v-interneti-a-praczyuye-na-biznes/

неділя, 12 жовтня 2014 р.

WordPress: враження від встановлення та перенесення блогу

Після кількох звернень клієнтів щодо створення й оновлення сайтів я знову встановив WordPress. До того працював із цією CMS багато років тому, тож хотілося оцінити її у власних завданнях. І скажу чесно: система сподобалася...

Що сподобалося

Насамперед — простота встановлення. У моєму середовищі воно зайняло менш ніж хвилину, а теми вдавалося швидко додавати з каталогу. Тоді це було одне з найшвидших встановлень, які я бачив. Простота й лаконічність справили чудове враження; на іншому сервері швидкість залежатиме від його підготовки та мережі.

Зручними були зрозумілі постійні посилання, зокрема з кириличними назвами, великий вибір тем і плагінів та їх встановлення з адміністративного інтерфейсу. Опис і знімки екрана допомагали оцінити розширення перед використанням: обираєш плагін, установлюєш, а якщо не сподобався — вимикаєш. Від розмаїття тем розбігалися очі. Здавалося, нарешті можна здійснити мою мрію — створювати багато сайтів за день :) Самі зрозумілі URL не гарантують високих позицій у пошуку, але полегшують організацію адрес сторінок.

Практичний результат теж порадував: за добу я переніс приблизно пів тисячі статей зі свого блогу. WordPress здався зручним інструментом для цього обсягу роботи.

Система має відкритий код і поширюється за GPLv2 або пізнішою версією. Водночас відкритість коду не означає, що хостинг, супровід, усі теми чи сторонні послуги безкоштовні.

Межі цього досвіду

На момент написання я не виявив суттєвих для себе недоліків. Це перше враження від конкретних робіт, а не вичерпна оцінка CMS для будь-якого проєкту. Розширювати сайт слід із перевіркою сумісності та якості потрібних компонентів.

Потрібно створити або оновити сайт? Обговорити завдання з K2 можна через WhatsApp: +380679016322.

четвер, 12 лютого 2009 р.

Світові новини на «Корпорації 2»: запуск розділу у 2009 році

У 2009 році на нашому сайті запрацював розділ світових новин. Для нього використали нову систему збирання новин, яку розробили на «Корпорації 2».

Новий варіант розділу тоді можна було переглянути за адресою http://corp2.net/news/allnews/.

Про імпорт новин і посторінкову навігацію також розповів у нотатці «RSS та навігація сторінками в “Корпорації 2 CMS”».

RSS та навігація сторінками в «Корпорації 2 CMS»

У лютому 2009 року в «Корпорації 2 CMS» з’явилися нові компоненти для роботи з новинами та переходу між сторінками.

Імпорт RSS і посторінкова навігація

  • rss_grabber — компонент збирання новин із RSS.
  • pages — компонент переходу між сторінками.

Також удосконалили компонент news, щоб він працював із великою кількістю новин.

Як компоненти працювали разом

На тестовому сайті показали весь сценарій: імпорт новин, виведення списку та перегортання його сторінок. Тодішня адреса демонстрації — http://image.corp2.net/news/allnews/.

Компоненти «Корпорація 2 CMS»: призначення й структура

У 2009 році «Корпорація 2 CMS» швидко розвивалася: ми вже розробили кілька десятків компонентів. Кожен відповідав за окреме завдання, а з їхніх викликів складалася функціональність сайту. Ось які компоненти на той момент уже були в системі.

Загальні компоненти

  • topmenu — меню сайту.
  • rewrite — робота зі зрозумілими URL, заголовками та перетворенням вмісту.
  • pathway — навігаційний ланцюжок, або «хлібні крихти».
  • search — пошук.
  • tiptop — порада дня.
  • inc_region — підключення окремої області сторінки.
  • map — карта сайту.

Облікові записи

  • auth — авторизація.
  • reg_user — реєстрація користувача.
  • forg_passwd — функція «згадати пароль».

Каталог товарів і замовлення

  • catalog_tov_dataset — клас роботи з SQL для каталогу.
  • catalog_tov — основний компонент каталогу.
  • group_tov і group_tov_map — групи товарів та їх подання в карті.
  • spis_tov — список товарів.
  • tov_detile — детальний опис товару.
  • scroll_tov — смуга прокручування товарів.
  • map_tov — подання товарів у компоненті map.
  • gtov_menu — меню груп товарів, яке часто розміщували ліворуч.
  • basket — кошик і оформлення замовлення.
  • basket_informer — кількість товарів у кошику та основний клас роботи з ним.

Адміністрування

  • page_editors — кнопки редагування статичної сторінки.
  • fckeditor — редактор HTML.
  • page_props — властивості сторінки.
  • edit_menu — редагування меню.

Три принципи, на яких ми будували систему

  1. Простота й лаконічність. Ми прагнули робити компоненти простими у використанні: типовий виклик часто займав лише один рядок.
  2. Модульність. Замість одного великого компонента — невеликі частини, кожна з яких розв’язує свою задачу.
  3. Повторне використання й перевірка. Ті самі невеликі компоненти застосовували в інших компонентах і різних проєктах. Це давало більше нагод перевірити їхню роботу та виправити помилки.

Такою була структура нашої CMS у цій версії: від меню та навігації до каталогу товарів, кошика й інструментів редагування сайту.

середа, 11 лютого 2009 р.

«Корпорація 2 CMS»: розробка системи для сайтів у 2009 році

У лютому 2009 року працювали над власною системою керування сайтами — «Корпорація 2 CMS».

Її створювали як систему, повністю інтегровану з «Корпорацією 2», і спиралися на ті самі принципи, які заклали в основу «Корпорації 2».

Перші веброботи на новій CMS планували показати найближчими днями.

CMS Made Simple: намір протестувати ще одну CMS

CMS з’являлися одна за одною! У 2009 році на сторінках Delphiplus помітив банер CMS Made Simple. Занотував тодішню адресу: http://www.cmsmadesimple.ru.

Зацікавився ще однією системою керування вмістом. Хотілося спробувати її в роботі й протестувати — планував узятися за це, якщо знайдеться час.

неділя, 6 квітня 2008 р.

Joomla: компоненти й ресурси з моєї робочої добірки

У квітні 2008 року я вирішив зібрати в одному місці корисні модулі й ресурси для Joomla. До списку потрапили фотогалереї, відео й музика, форум, редактор, навчання та технічна підтримка. Адреси нижче відтворюють мою тодішню добірку.

Фотогалереї та візуальний редактор

  • Фотогалерея DatsoGallery — http://www.datso.fr/downloads.html
  • Фотогалерея — http://www.gotgtek.net
  • Візуальний редактор — http://www.joomlafckeditor.com/

Відео й музичні каталоги

  • Каталог відео — http://extensions.joomla.org/component/option,com_mtree/task,viewlink/link_id,1628/Itemid,35/
  • Музичні та відеокаталоги Zina — http://sourceforge.net/projects/zina
  • Музичний каталог та вставлення музики в текст — http://www.quoc-huy.com/
  • MusicBox — http://joomlacode.org/gf/project/musicbox/frs/

Форум FireBoard і шаблони

  • Форум FireBoard — http://joomlacode.org/gf/project/fireboard/frs/
  • Шаблони FireBoard — http://ext.joom.ru/fireboard-templates.html

Підтримка, навчання, портфоліо й мови

  • Розширення технічної підтримки — http://extensions.joomla.org/index.php?option=com_mtree&task=listcats&cat_id=1784&Itemid=35
  • Розширення для навчання — http://extensions.joomla.org/component/option,com_mtree/task,listcats/cat_id,1852/Itemid,35/
  • Розширення портфоліо — http://extensions.joomla.org/component/option,com_mtree/task,listcats/cat_id,1869/Itemid,35/
  • Багатомовність: Joom!Fish — http://www.joomfish.net/downloads/

Сайти спільноти та інструменти розробника

  • JoomlaCode — http://joomlacode.org
  • Російськомовний ресурс — http://joomla.ru
  • Каталог розширень — http://extensions.joomla.org/
  • Портал про Joomla — joomlaportal.ru
  • Навчальні матеріали — http://myjoomla.ru
  • Україномовний ресурс — http://joomla-ua.org
  • Розширення Joomla — http://www.joomla-extensions.ru
  • Інструменти розробника — http://design4free.org

Як перевіряти розширення для свого проєкту

Почніть з офіційного Joomla Extensions Directory: у каталозі є добірки за сумісними версіями Joomla та сторінки конкретних розширень. Зіставте їх із версією свого сайту й вимогами розробника компонента. Однієї згадки назви в добірці 2008 року недостатньо для вибору пакета до нового проєкту.

неділя, 11 листопада 2007 р.

Друга власна вебсистема: порівняльний тест 2007 року

Після першого тесту індивідуально розробленого сайту я вирішив перевірити ще одну таку систему. Адже власні розробки бувають різними, а швидкість може залежати й від наповнення сторінки. У листопаді 2007 року ми запустили на titan-r перевірку головної сторінки navstrechu.com.

Однаковий обсяг запитів — інший сайт

Параметри навантаження залишилися знайомими: один мільйон запитів, п’ять одночасно. Початкова довжина документа тут становила 20820 байтів, у відповіді зазначався nginx/0.4.13. За такого сценарію ми знову перевіряли одну адресу, а не повний шлях користувача сайтом.

Повний журнал вимірювання

root@titan-r:~# ab -c 5 -n 1000000 http://navstrechu.com/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking navstrechu.com (be patient)
Completed 100000 requests
Completed 200000 requests
Completed 300000 requests
Completed 400000 requests
Completed 500000 requests
Completed 600000 requests
Completed 700000 requests
Completed 800000 requests
Completed 900000 requests
Finished 1000000 requests


Server Software:        nginx/0.4.13
Server Hostname:        navstrechu.com
Server Port:            80

Document Path:          /
Document Length:        20820 bytes

Concurrency Level:      5
Time taken for tests:   2296.412062 seconds
Complete requests:      1000000
Failed requests:        0
Write errors:           0
Total transferred:      -462836480 bytes
HTML transferred:       -654836480 bytes
Requests per second:    435.46 [#/sec] (mean)
Time per request:       11.482 [ms] (mean)
Time per request:       2.296 [ms] (mean, across all concurrent requests)
Transfer rate:          -196.82 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     5   10  12.0     10    5053
Waiting:        5    9   9.6      9    5051
Total:          5   10  12.0     10    5053

Percentage of the requests served within a certain time (ms)
  50%     10
  66%     12
  75%     13
  80%     14
  90%     17
  95%     18
  98%     21
  99%     23
 100%   5053 (longest request)

Мільйон запитів приблизно за 38 хвилин

Прогін завершився за 2296.412062 секунди — приблизно 38,27 хвилини. Середня швидкість становила 435.46 запиту/с. ApacheBench не зафіксував невдалих запитів або помилок запису.

Половина запитів уклалася у 10 мс, 95% — у 18 мс, 99% — у 23 мс. При цьому найдовша відповідь потребувала 5053 мс. Цей розрив між типовою та максимальною затримкою теж є частиною результату.

Від’ємні значення обсягу та швидкості передавання не можна трактувати як фізичний трафік. У журналі є аномалія лічильників; для встановлення її причини потрібні додаткові дані. Числа у первинному виводі збережено.

Чому висновок змінився

У попередньому тесті osan-koeln.net я отримав 190.38 запиту/с. Тут результат був приблизно у 2,29 раза вищим. Це вже показувало, наскільки різними можуть бути результати двох індивідуальних розробок, хоча причину різниці самі ці журнали не встановлюють.

Тоді я також записав оцінку, що цей сайт випереджав Joomla майже вдвічі. Для перевірки саме такого порівняння потрібен відповідний тест Joomla з узгодженими умовами. Натомість практичний висновок із двох власних систем був очевидний: одна назва класу «індивідуальна розробка» швидкодію не визначає.

Наступне запитання — сторінка з контентом

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

Тому мене зацікавило інше: як зміниться швидкість, якщо перевіряти внутрішню сторінку з контентом? Саме такий наступний крок міг показати різницю між швидкою головною та іншими сценаріями роботи сайту.

Власноруч розроблена вебсистема: тест головної сторінки 2007 року

У листопаді 2007 року я вирішив перевірити поширене твердження: чи справді стандартні CMS працюють швидше за індивідуально розроблені сайти? Для цього запустив тривалий тест головної сторінки osan-koeln.net на сервері titan-r.

Умови перевірки

ApacheBench виконав мільйон запитів із паралельністю 5. Головна сторінка мала довжину 33326 байтів, а сервер представлявся як nginx/0.4.13. Це перевірка однієї адреси, без переходів між розділами й відтворення різних дій відвідувачів.

Повний журнал тесту

root@titan-r:~# ab -c 5 -n 1000000 http://osan-koeln.net/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking osan-koeln.net (be patient)
Completed 100000 requests
Completed 200000 requests
Completed 300000 requests
Completed 400000 requests
Completed 500000 requests
Completed 600000 requests
Completed 700000 requests
Completed 800000 requests
Completed 900000 requests
Finished 1000000 requests


Server Software:        nginx/0.4.13
Server Hostname:        osan-koeln.net
Server Port:            80

Document Path:          /
Document Length:        33326 bytes

Concurrency Level:      5
Time taken for tests:   5252.648192 seconds
Complete requests:      1000000
Failed requests:        0
Write errors:           0
Total transferred:      -646738368 bytes
HTML transferred:       -1033738368 bytes
Requests per second:    190.38 [#/sec] (mean)
Time per request:       26.263 [ms] (mean)
Time per request:       5.253 [ms] (mean, across all concurrent requests)
Transfer rate:          -120.24 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       4
Processing:    12   25  45.3     23   10587
Waiting:       11   23  40.7     22   10581
Total:         12   25  45.3     23   10587

Percentage of the requests served within a certain time (ms)
  50%     23
  66%     26
  75%     29
  80%     31
  90%     37
  95%     43
  98%     51
  99%     60
 100%  10587 (longest request)

Що показали цифри

Прогін тривав 5252.648192 секунди — приблизно 87,54 хвилини. Середній результат становив 190.38 запиту за секунду. У журналі немає невдалих запитів або помилок запису.

Медіанний час відповіді становив 23 мс; 95% запитів уклалися у 43 мс, 99% — у 60 мс. Водночас найдовший запит тривав 10587 мс, тобто понад десять секунд. Тому однієї середньої швидкості замало, щоб описати всі затримки.

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

Порівняння зі стандартними CMS

Тоді я записав, що більшість перевірених мною CMS були швидшими, «Бітрікс» — повільнішим, а Joomla випереджала цей сайт приблизно в півтора раза. Проте в цій нотатці немає парного журналу Joomla з тотожними даними та налаштуваннями. Саме наведений прогін не дозволяє перевірити таке співвідношення.

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

Висновок для вибору системи

Цей тест дав числовий результат для конкретного сайту у 2007 році, але не встановив переможця між усіма готовими CMS та індивідуальними рішеннями. Для такого порівняння потрібні однакові дані, сценарії й умови роботи. Метод читання показників описано в документації ApacheBench.

неділя, 4 листопада 2007 р.

Energine на titan-r: навантажувальний тест 2007 року

У листопаді 2007 року я перевіряв Energine на сервері titan-r. Очікував, що використані в системі технології дадуть перевагу у швидкодії, але отриманий результат мене розчарував.

За моїми тодішніми тестами Energine виявилася повільнішою за Joomla; в тих самих нотатках я згадував і швидші результати phpNuke та Drupal. Водночас вона випередила протестований мною «Бітрікс». Щоправда, обсяг інформації на сайтах був неспівмірним — і це суттєво обмежувало таке порівняння.

Що саме вимірювалося

ApacheBench звертався до головної сторінки i1.kiev.ua. Параметр -n 100000 задавав кількість запитів, а -c 5 — п’ять одночасних запитів. У відповідях сервер представлявся як nginx/0.4.13, довжина документа становила 4023 байти.

Журнал тесту

root@titan-r:~# ab -c 5 -n 100000 http://i1.kiev.ua/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking i1.kiev.ua (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Finished 100000 requests


Server Software:        nginx/0.4.13
Server Hostname:        i1.kiev.ua
Server Port:            80

Document Path:          /
Document Length:        4023 bytes

Concurrency Level:      5
Time taken for tests:   4574.631725 seconds
Complete requests:      100000
Failed requests:        5
   (Connect: 0, Length: 5, Exceptions: 0)
Write errors:           0
Non-2xx responses:      5
Total transferred:      446779435 bytes
HTML transferred:       402280850 bytes
Requests per second:    21.86 [#/sec] (mean)
Time per request:       228.732 [ms] (mean)
Time per request:       45.746 [ms] (mean, across all concurrent requests)
Transfer rate:          95.38 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     0  228 106.2    205    1613
Waiting:        0  227 106.1    204    1613
Total:          0  228 106.2    205    1613

Percentage of the requests served within a certain time (ms)
  50%    205
  66%    228
  75%    240
  80%    250
  90%    296
  95%    429
  98%    591
  99%    726
 100%   1613 (longest request)

Як читати результат

На 100 000 запитів пішло 4574.631725 секунди, а середня пропускна здатність становила 21.86 запиту за секунду. Половина запитів уклалася у 205 мс, 95% — у 429 мс; найдовший тривав 1613 мс.

Два рядки Time per request описують різні способи усереднення: 228.732 мс враховує рівень паралельності, а 45.746 мс — загальний час, поділений на кількість запитів. Друге число не означає, що окремий відвідувач чекав лише 45.746 мс.

Окремо зафіксовано п’ять невдалих запитів із відмінною довжиною відповіді та п’ять відповідей поза діапазоном 2xx. За підсумковим журналом не можна визначити їхні точні HTTP-коди чи причину зміни довжини. Опис цих полів наведено в документації ApacheBench.

Який висновок я зробив

Очікуваної переваги Energine у цій перевірці я не побачив. Але результат стосується конкретної сторінки, вмісту й серверного оточення 2007 року. Для висновку про самі CMS потрібне зіставлення однакового навантаження й однакових даних, а в моєму порівнянні ці умови не були витримані.

Сайт на «Бітрікс»: журнал навантажувального тесту 2007 року

У листопаді 2007 року ми перевірили сайт budmart.nerusoft.com на CMS «Бітрікс». Було виконано 100 000 запитів із паралельністю 5. Зафіксовано 9254.840333 с, 10.81 запиту/с і середній показник Time per request 462.742 мс.

Умови та журнал вимірювання

Тест стосувався головної сторінки завдовжки 25 847 байтів у тодішній серверній конфігурації. У звіті видно nginx/0.4.13 та ApacheBench 2.0.40-dev. Паралельність 5 означає п’ять одночасно виконуваних запитів, а 100 000 — їх загальну кількість за запуск.

root@titan-r:~# ab -c 5 -n 100000 http://budmart.nerusoft.com/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking budmart.nerusoft.com (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Finished 100000 requests


Server Software:        nginx/0.4.13
Server Hostname:        budmart.nerusoft.com
Server Port:            80

Document Path:          /
Document Length:        25847 bytes

Concurrency Level:      5
Time taken for tests:   9254.840333 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      -1653067296 bytes
HTML transferred:       -1710267296 bytes
Requests per second:    10.81 [#/sec] (mean)
Time per request:       462.742 [ms] (mean)
Time per request:       92.548 [ms] (mean, across all concurrent requests)
Transfer rate:          -174.43 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   331  462 103.7    445    3993
Waiting:      317  446 102.6    430    3932
Total:        331  462 103.7    445    3993

Percentage of the requests served within a certain time (ms)
  50%    445
  66%    500
  75%    533
  80%    555
  90%    610
  95%    633
  98%    658
  99%    682
 100%   3993 (longest request)

Як читати ці результати

Повний запуск тривав близько 154 хвилин. Медіанний час у таблиці — 445 мс, 95% запитів уклалися в 633 мс, а найдовший тривав 3993 мс. Тому середнє значення 462,742 мс не описує кожну відповідь: у вимірюванні були й значно довші запити.

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

Офіційна документація ApacheBench. Під час власного порівняння слід однаково визначити сторінки, кешування, версії й навантаження та тестувати ресурс із погодженим доступом. Інакше різницю між інсталяціями легко помилково приписати самій CMS.

Joomla / Joostina: продуктивність тестового сайту 2007 року

У листопаді 2007 року я доповнив попередній тест phpNuke перевіркою сайту на Joomla / Joostina за адресою 3r.kiev.ua. Ми готували цей варіант для нашого бренду на заміну тодішньому nerusoft.com. Виконано 100 000 запитів; у журналі наведено 3487.360345 с та 28.67 запиту/с.

Умови та журнал вимірювання

У запуску ApacheBench було задано паралельність 5; перевірялася головна сторінка завдовжки 10 422 байти. Сервер повідомляв nginx/0.4.13. Повний журнал важливий не лише для порівняння швидкості: він показує й те, за яким критерієм частину відповідей позначено невдалими.

root@titan-r:~# ab -c 5 -n 100000 http://3r.kiev.ua/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 3r.kiev.ua (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Finished 100000 requests


Server Software:        nginx/0.4.13
Server Hostname:        3r.kiev.ua
Server Port:            80

Document Path:          /
Document Length:        10422 bytes

Concurrency Level:      5
Time taken for tests:   3487.360345 seconds
Complete requests:      100000
Failed requests:        9951
   (Connect: 0, Length: 9951, Exceptions: 0)
Write errors:           0
Total transferred:      1089389537 bytes
HTML transferred:       1042189537 bytes
Requests per second:    28.67 [#/sec] (mean)
Time per request:       174.368 [ms] (mean)
Time per request:       34.874 [ms] (mean, across all concurrent requests)
Transfer rate:          305.06 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   116  173  44.4    168     402
Waiting:      112  167  43.9    162     397
Total:        116  173  44.4    168     402

Percentage of the requests served within a certain time (ms)
  50%    168
  66%    193
  75%    209
  80%    219
  90%    234
  95%    247
  98%    269
  99%    284
 100%    402 (longest request)

Як читати ці результати

Важливо врахувати 9951 невдалий запит за критерієм Length. Це не 9951 помилка з’єднання: у відповідному рядку Connect дорівнює нулю. ApacheBench може позначати відмінність довжини відповіді як помилку; за цим журналом не можна визначити, чи всі такі відповіді були функціонально неправильними. У нашому тодішньому порівнянні цей варіант Joomla виявився «важчим» і тест тривав довше, ніж для phpNuke. Це спостереження стосується конкретних сайтів і налаштувань. Далі я планував перевірити «Бітрікс»; журнал того тесту зберігає продовження серії.

Офіційна документація ApacheBench. У наведеному результаті медіана становить 168 мс, 95% відповідей — у межах 247 мс, найдовша — 402 мс. Для повторного порівняння потрібен погоджений тестовий ресурс та однаковий сценарій; історичний URL сам по собі не задає таких умов.

неділя, 21 жовтня 2007 р.

Joostina на базі Joomla: досвід тестування у 2007 році

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

Що було зручним у збірці

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

Загалом враження залишилося непоганим. Мені було важливо не лише те, як CMS виглядає, а й наскільки зрозуміло з нею працювати щодня.

Плани для основного сайту

Я розглядав Joostina для нашого основного сайту. Робота тоді тривала на i2.kiev.ua. Коли буде готовий дизайн для бренду RS™, планували перенести сайт на основний домен nerusoft.com.

Energine після виправлення панелі адміністратора: враження від тестування

У жовтні 2007 року разом із розробниками Energine вдалося усунути проблему відображення панелі адміністратора. Після цього я нарешті зміг попрацювати в CMS і перевірити її на практиці. Цю проблему я описував у першій нотатці про встановлення Energine.

Редагування контенту

Загалом враження в мене залишилося позитивне: у Internet Explorer сторінку можна було редагувати безпосередньо на екрані, а зміна пунктів меню здавалася простою.

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

Стан тестованої версії

Робота з контентом уже була доступна. Інші модулі в протестованому тоді постачанні ще були відсутні: вони перебували в розробці й налагодженні.

Тестування я планував продовжувати на i1.kiev.ua. Після появи панелі вже можна було оцінювати щоденну роботу з контентом, а не лише процес встановлення.

пʼятниця, 19 жовтня 2007 р.

Перший тест Energine: встановлення CMS та враження 2007 року

У жовтні 2007 року я помітив нову для себе CMS Energine й вирішив перевірити її в роботі. Мене зацікавили опис системи, її зв’язок із командою Colocall та заявлена тоді ліцензія LGPL.

Встановлення: запустилося майже все

Дистрибутив я завантажив із energine.org. Встановлення виявилося дещо заплутаним: чимало дій довелося виконувати вручну. Після певних зусиль систему вдалося запустити — але після входу в адміністративну частину сама панель адміністратора не з’явилася.

На щастя, розробники відгукнулися на мої запитання. На момент цієї першої спроби ми разом працювали над проблемою. Надіявся, що переможемо :)

Чим система зачепила

Скажу чесно: Energine справив цікаве враження. Найбільше сподобалися простота побудови, доступна документація API та лаконічний код без зайвого. Для розробника це важливо: потрібно не лише встановити CMS, а й розібратися, як її пристосовувати до власних завдань.

У моєму тодішньому варіанті використовувалися MySQL з InnoDB та вебсервер nginx; розглядався й варіант з Apache. Редагування в Internet Explorer було побудовано так, що після входу можна було змінювати інформацію безпосередньо на екрані.

Очікування від продуктивності й подальші плани

Я покладав великі надії на легкість сервера та роботу під навантаженням. Проте сама назва nginx або InnoDB не давала відповіді, скільки запитів витримає конкретний сайт: це залежало б від коду, запитів до бази, конфігурації та обладнання. Числових результатів навантажувального тесту на цьому етапі в мене не було.

Якби подальше тестування пройшло успішно, я планував застосувати Energine на nerusoft.com і в програмних рішеннях під брендом RS™. Спочатку потрібно було подолати проблему з панеллю та перевірити систему у власних робочих сценаріях.

вівторок, 2 жовтня 2007 р.

Drupal для інформаційного порталу: власний проєкт 2007 року

Восени 2007 року я нарешті взявся за власний сайт на Drupal. Давно хотілося попрацювати і з Drupal, і з Joomla: на Joomla я вже створював сайти для замовників, а для Drupal обрав свій проєкт.

Портал для новин і пошуку

За власні кошти я створив інформаційно-комерційний сайт kiev2000.kiev.ua. Його задум був зосереджений на двох завданнях: збирати новини та допомагати знаходити потрібне серед накопичених матеріалів.

Для цих цілей Drupal тоді справив на мене дуже хороше враження. Це був уже досвід роботи над конкретним сайтом, а не лише бажання спробувати ще одну CMS.

четвер, 27 вересня 2007 р.

Чому верстка дизайну сайту потребує часу: макет, браузери та CMS

«Порізати дизайн — це просто, тут небагато роботи». Я часто чув таку оцінку, але на практиці все залежить від вимог. Одне діло — відтворити просту картинку в одному вікні браузера, зовсім інше — зробити повноцінну сторінку для живого порталу. Ще у 2007 році я виділив чотири основні джерела цієї складності.

Від малюнка до структури сторінки

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

Точність макета — лише частина роботи. Сторінка має поводитися передбачувано, коли змінюється розмір вікна або обсяг тексту. Статична картинка цього не показує: довгий заголовок, інше меню чи новина з великим зображенням можуть вимагати додаткових рішень.

Важлива й швидкість завантаження. У 2007 році я наводив приклад: великий графічний градієнт часто можна було замінити маленьким зображенням із повторенням. Це зменшувало обсяг відповідної графіки. Сьогодні простий градієнт можна створити без окремого растрового файла функцією linear-gradient() у CSS. Завдання залишилося тим самим — відтворити задум без зайвих витрат на завантаження, хоча інструменти змінилися.

Різні браузери та версії

У 2007 році мені доводилося перевіряти сторінки, зокрема, в Internet Explorer, Opera та Firefox. Відмінності відображення між браузерами й версіями змушували витрачати час на налагодження та компроміси.

Отже, готовність макета ще не означала готовності шаблону: потрібна була перевірка фактичної поведінки в середовищах користувачів.

Текст і доступність вмісту для пошуку

Ще одна спокуса того часу — зібрати весь сайт у Flash, де легше було зафіксувати розташування об’єктів. Але керований вигляд не замінює доступного тексту й зрозумілої структури сторінки. Я наполягав, що основний контент потрібно представляти засобами HTML, CSS і JavaScript, а не ховати його всередині графічної композиції.

Для нового сайту питання Flash уже закрите: Adobe припинила підтримку Flash Player 31 грудня 2020 року й заблокувала відтворення Flash-контенту в ньому з 12 січня 2021 року. Практичний висновок ширший за цю технологію: основний текст і навігація повинні залишатися частиною вебсторінки, а не лише зображенням її зовнішнього вигляду.

Інтеграція з CMS

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

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

Наприклад, дизайнер намалював меню на п’ять коротких пунктів, а CMS отримала дванадцять довгих назв із підменю. Або блок новин має вміщувати і коротке повідомлення без фото, і великий матеріал з ілюстрацією. Це не «поганий контент», а стани, які шаблон має обробляти. Якщо їх не погодити заздалегідь, витрати з’являться вже під час інтеграції.

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

K2 відкрила курс з ERP: 61 урок, практика й сертифікат

Перший день у новій ERP часто починається з пошуку потрібної кнопки. Наступний виклик складніший: зрозуміти, що зміниться після натискання. ...