Як ми створили CRM-систему для громадської організації

Привіт! Я Ганна Ліхтман, Software Lead у GlobalLogic. Я фулстек-розробниця, викладачка GlobalLogic Education, і час від часу створюю власні пет-проєкти. Десять років тому я вирішила зробити добру справу та організувала пункт допомоги нужденними сім’ям у Бучанському районі, де ми живемо. З 2022 року наша організація стала допомагати й сім’ям ВПО.

В останні два роки багато з нас займаються волонтерством, тож далі я хочу розповісти, як ми розробили CRM-систему для роботи нашої ГО, а саме для матеріального обліку, видачі допомоги та обліку тих, хто її отримує.

Чим займається наша громадська організація

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

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

Для чого нам CRM-система

Під час роботи в ГО ми зіштовхнулися з кількома проблемами, які пізніше розв’язала наша CRM-система.

1. Облік отримувачів мав бути прозорим, аби всі отримували саме те, чого вони потребують, і допомога розподілялася чесно. На початку повномасштабного вторгнення цієї проблеми не було, люди зверталися тільки по необхідне, отримували допомогу і її вистачало. Згодом ми почали помічати, що деякі сім’ї звертаються частіше, через що інші сім’ї не можуть отримати навіть базові речі.
2. Багато ручного ведення звітності, яку ми готували і для себе, і для спонсорів. Списки та документи писалися вручну. Буквально все писалось від руки на папері прямо під час роздачі. Це суттєво розтягувало видачу гуманітарних речей. Ми вирішили автоматизувати ці записи.
3. Необхідно було вести облік на складі, відслідковувати залишки та роздачі, щоб мати змогу пропонувати людям потрібні речі та засоби. Допомоги та охочих її отримати ставало все більше, потік людей та обіг речей зростали. Ми перестали розуміти наявність позицій — наприклад, скільки у нас засобів гігієни є на складі? Що ми можемо пообіцяти людям? Чи можемо ми запросити 100 людей на роздачу цього тижня?

З чого ми почали

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

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

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

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

Проте Excel — це зовсім незручний інструмент для нашої задачі. Натиснути на просту та зрозумілу кнопку в інтерфейсі набагато швидше. Тому, коли черга дійшла до створення CRM, ми просили дизайнерів розробити такий дизайн, який був би зрозумілий для будь-кого (як я казала тоді, щоб і мій кіт зрозумів, куди натискати).

Структура рішення та модулі системи

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

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

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

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

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

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

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

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

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

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

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

Я вважаю, що частинка людського потрібна, і віддавати все комп’ютерам не варто :)

Як формується роздача

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

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

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

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

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

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

Як обирали інструменти та стек

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

Тоді я займала позицію Senior-розробника й переходила на позицію ліда. Проте, щоби продумати всі зв’язки, зрозуміти, як система має працювати, треба бути архітектором. Я постійно стикалася з тим, що щось було непродумано — особливо це стало відчутно, коли у нас з’явилася команда розробників (про неї далі). Але ми впоралися.

Я обирала ті інструменти та бібліотеки, з якими працювала сама, щоб у разі чого я могла підхопити, закінчити або спрямувати роботу. Стек — Postgres, Nest і React.

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

• Для бекенд-розробки обрала Node.js, тому що знаю JavaScript. Я вирішила трішки схитрити, взяла бібілотеку на Node.js — NestJS. Вона простіша в розробці, багато чого вже йде з коробки, треба просто підібрати модулі.
• Базу даних я робила на PostgreSQL, бо тут все на таблицях, для мене це було логічним вибором.

Мені дуже допоміг мій чоловік, він DevOps. Він підняв AWS-сервер, на якому розгорнув GitLab. Все, що стосувалось інфраструктури, зробив він: підняв всі бази даних, зробив зв’язки, завів хост, подбав про безпеку тощо.

Я запустила два репозиторії: один для бекенду, один для фронтенду. Створила проєкти, базову структуру тек, розподілила, де що має лежати, підібрала однакові лінтери, інструменти для відстежування чистоти коду та тестингу.

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

Для нетехнічної сторони спочатку думали про Jira, але для маленької команди в кілька розробників це було недоцільно. Обрали просто канбан-дошку, де ми «перетягували» картки для трекінгу задач.

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

Як шукали розробників

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

Але в мене було дві додаткові мотивації спробувати зробити це самій:

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

Спершу я вирішила розмістити вакансії на Djinni, але швидко відмовилася від цієї ідеї через комісію.

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

З 2020 року я викладаю в GlobalLogic Education, провела ReactNative GlobalLogic BaseCamp, читала курси про Git та OSI. Точно знаю, як найкраще донести інформацію: як теоретичну, так і практичну. Плюс, це можливість попрацювати на добру справу, отримати досвід та заробити.

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

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

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

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

Поради тим, хто планує почати власний проєкт

1. Команда має визначити, які проблеми та болі має виправити ваш проєкт. У чому його цінність, чим він може вам допомогти, що автоматизувати чи спростити тощо.
2. Спершу пошукайте готові рішення. Можливо, хтось вже робив це до вас. Якщо воно мінімально відрізняється від того, що вам треба, то, як на мене, не варто вигадувати велосипед.
3. На пошуковий запит у гуглі «як почати проєкт» ви побачите мільйон статей і відео. Втім, я раджу почати. Візьміть олівець та папір і намалюйте свій майбутній проєкт. Це може бути схема інтерфейсу, а може бути малюнок зв’язків бази даних. У будь-якому випадку — це дасть старт спіралі, яку ви будете розкручувати, розуміючи, що дійсно вам треба, що варто змінити, а на що звернути увагу.
4. Я теж починала з пошуку статей «як розпочати проєкт», але поки не відкрила draw.io і не намалювала просту схему інтерфейсу (бо, в першу чергу, я — Frontend-розробник) на палках і квадратиках, нічого не рухалось.

Висновки

Розробка великої CRM-системи з нуля — це завдання, що вимагає великих зусиль та терпіння не тільки від людини, яка це започаткувала, але й від усіх учасників процесу. Як Product Owner та архітектор одночасно, я зіштовхнулась з низкою складнощів, які вимагали уваги та невідкладного вирішення.

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

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

Адже іноді покращення нашої системи починалися з «Ой, ну не знаю, а можна по-іншому?». І тут стоїть задача зрозуміти, що саме має на увазі користувач під «по-іншому».

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

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

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

Хочу скористатися нагодою та подякувати організації Nova Ukraine — вони багато нам допомагають і коштами, і загалом.

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