Мобільний додаток проти шахраїв і паперової тяганини в автострахуванні

Сьогодні хочемо поділитися нашим досвідом в розборі автомобілів. Ні, ми не плануємо влаштовувати випуск Top Gear. У нас для вас інша тема – як за допомогою мобільного додатку перевести в цифровий формат паперову тяганину навколо добровільного автострахування – всім відомого КАСКО.

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



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



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

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



Одне-єдине додаток вирішує цілий ряд завдань страхової компанії:
  1. Забезпечує більш легкий «вхід у професію». Замість очного навчання агентів, забезпечення їх фотоапаратами, тепер достатньо дати агенту посилання на скачування програми.
  2. При цьому підвищується якість роботи агентів. За рахунок зашитих в додаток множинних «захист від дурня» процедура передбачає неухильне дотримання технології.
  3. І одночасно така технологія ефективно захищає від усіляких махінацій та шахрайства за рахунок передбачених у програмі заходів контролю та обмежень.
В результаті страхова компанія одночасно отримала можливість знизити витрати на укладення договору КАСКО, підвищити якість роботи агентів і захиститися від шахрайства.

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

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

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



Щоб реалізувати таку синхронізацію, ми використовували стандартну бібліотеку для роботи з календарем EventKit:
Синхронізація зі стандартним календарем
(void)syncEventForSurvey:(Survey *)survey
completion:(void (^)(NSError *))completion
{
if (!survey.dateScheduled)
return;
[self.eventStore requestAccessToEntityType:EKEntityTypeEvent
completion:^(BOOL granted, NSError *error)
{
dispatch_async(dispatch_get_main_queue(), ^{
if (!granted || error) {
if (completion)
completion(error);
return;
}

NSTimeInterval oneHour = 60*60;
EKEvent *event = nil;
if (survey.eventIdentifier) {
event = [self.eventStore eventWithIdentifier:survey.eventIdentifier];
}
if (!event) {
event = [EKEvent eventWithEventStore:self.eventStore];
event.calendar = [self surveysCalendar];

event.title = survey.title;

NSTimeInterval alarmOffset = -oneHour;
EKAlarm *alarm = [EKAlarm alarmWithRelativeOffset:alarmOffset];
event.alarms = @[alarm];
}

event.startDate = survey.dateScheduled;
NSTimeInterval surveyDuration = oneHour;
event.a list = [event.startDate dateByAddingTimeInterval:surveyDuration];

NSError *saveError = nil;
[self.eventStore saveEvent:event
span:EKSpanThisEvent
commit:YES
error:&saveError];
if (!saveError) {
survey.eventIdentifier = event.eventIdentifier;
}
if (completion)
completion(saveError);
});
}];
}



eventStore — це просто [[EKEventStore alloc] init];
surveysCalendar — трохи складніше:

surveysCalendar
(EKCalendar *)surveysCalendar
{
NSString *calendarTitle = @"Огляди ТЗ";

EKCalendar *calendar = nil;
if (self.surveysCalendarIdentifier) {
calendar = [self.eventStore calendarWithIdentifier:self.surveysCalendarIdentifier];
}
if (!calendar) {
NSArray *allCalendars = [self.eventStore calendarsForEntityType:EKEntityTypeEvent];
calendar = [allCalendars etr_filter:^BOOL(EKCalendar *obj) {
return [obj.title isEqualToString:calendarTitle];
}].firstObject;
}
if (!calendar) {
calendar = [EKCalendar calendarForEntityType:EKEntityTypeEvent
eventStore:self.eventStore];
calendar.source = self.eventStore.defaultCalendarForNewEvents.source;
calendar.title = calendarTitle;
[self.eventStore saveCalendar:calendar
commit:YES
error:nil];
self.surveysCalendarIdentifier = calendar.calendarIdentifier;
}
return calendar;
}


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

2. Проведення огляду
Для проведення огляду користувач вибирає об'єкт з переліку запланованих або нещодавно завантажених заявок на огляд і натискає на кнопку «Оглянути». Сам огляд складається з двох частин – огляд транспортного засобу та додавання документів.



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

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


Для запобігання «підробки» фото в додатку реалізовано декілька обмежень:
  • обмеження часу огляду – 30 хвилин,
  • фіксування геолокації кожного фото,
  • немає можливості додавати фотографії з бібліотеки смартфона.


2.1. Таймер, або встигнути за 30 хвилин
Як тільки користувач натискає кнопку «Почати огляд», запускається відлік часу. І на всіх екранах програми в режимі проведення огляду відображається таймер. У разі, якщо огляд транспортного засобу (ТЗ) не був проведений за 30 хвилин, всі фотографії, зроблені для цього огляду, видаляються, і огляд треба починати заново. Таке обмеження дозволяє запобігти обманне фотографування різних автомобілів для одного огляду.

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

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

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

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

2.3. Коректна фотофіксація
Фотографії, які використовуються в програмі, створюються та зберігаються тільки в додатку. Немає можливості зберегти фотографії у бібліотеку або передати їх куди-небудь, крім сервера страхової компанії. Це означає, що агент не зможе підробити фото, а фото ТЗ – не попадуть в чужі руки.

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



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



У додатку на макеті авто агент вибирає деталь ТЗ, на якій є ушкодження, вона виділяється кольором, і далі, програма переходить до етапу фотографування пошкодження.

Щоб реалізувати виділення на схемі криволінійних елементів (а деталі авто всі такі), ми використовували криві Безьє, отримані з формату SVG (Scalable Vector Graphics).

Криві Безьє дозволяють задати рівняння складних кривих, а в нашому випадку – контурів деталей автомобіля, а SVG формат двовимірних зображень, заснований на XML. Цікаво, що криві Безьє були розроблені саме для проектування кузовних деталей автомобілів.
Детальніше про кривих і SVG можна прочитати тут:
ru.wikipedia.org/wiki/Кривая_Безье
en.wikipedia.org/wiki/Scalable_Vector_Graphics

А наш рецепт вибору деталі на схемі виглядає так:
Спочатку дизайнери намалювали схему машини в трьох проекціях в SVG. Зображення SVG формату ми сконвертировали в набір окремих файлів деталей у вигляді кривих Безьє (для цього можна використовувати PocketSVG — github.com/arielelkin/PocketSVG ).

Всі файли .bezier додали в проект і використовували на екрані зі схемою: використовується фонова картинка з автомобілем, а зверху додаються деталі з UIBezierPath:
Робота з кривими Безьє
(void)awakeFromNib {
[super awakeFromNib];
NSArray *carParts = [SurveyStructure sharedStructure].carParts;
NSMutableArray *newLayers = [NSMutableArray array];
for (SurveyStructureCarPart* part in carParts) {
@autoreleasepool {
NSString *filepath = [[NSBundle mainBundle] pathForResource:part.identifier ofType:@"bezier"];
UIBezierPath *bezier = [NSKeyedUnarchiver unarchiveObjectWithFile:filepath];
CarPartLayer* layer = [[CarPartLayer alloc] initWithCarPart:part];
layer.anchorPoint = CGPointZero;
layer.path = bezier.CGPath;
layer.actions = @{@"fillColor": [NSNull null], @"opacity": [NSNull null]};
[newLayers addObject:layer];
[self.layersContainer.layer insertSublayer:layer atIndex:0];
}
}
self.carPartLayers = newLayers;
} 

По натисненню відстежуємо і позначаємо деталь:
- (void)hightlightPartAtPoint:(CGPoint)point {
for (CarPartLayer *layer in self.carPartLayers) {
if (CGPathContainsPoint(layer.path, NULL, point, false) {
if (self.highlightedLayer != layer) {
self.highlightedLayer = layer;
}
return;
}
}

if (self.highlightedLayer != nil) {
self.highlightedLayer = nil;
}
}



Для зручності вибору деталі на схемі використовується «збільшувальне скло» (наприклад, cocoapods.org/pods/iOS-MagnifyingGlass ).

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

3.1. Відправка по 3G
Відправка оглядів проводиться в тлі. І коли додаток запущено, і коли додаток в бекграунді. У синглтоне UploadManager використовується FetchResultsController, вибирає зі списку оглядів об'єкти в статусі «На відправку». При перекладі якогось огляду на відправку, фетчер повідомляє менеджеру, що необхідно завантажити. Менеджер завантажує дані з огляду на сервер, і змінює статус об'єкта. Після цього виконується перевірка щодо наявності інших оглядів на відправку. Якщо інших договорів у цей момент немає, менеджер завантаження буде чекати наступної нотифікації від фетчера.



Щоб додаток відправляло дані по оглядам у бекграунді, ми додали backgroud task:
Синхронізація в бекграунді
(void)applicationDidEnterBackground:(UIApplication *)application
{
if ([[UploadSurveysManager sharedManager] isNeedUpload]) {
self.bgTask = [application beginBackgroundTaskWithExpirationhandler:^{
[application endBackgroundTask:self.bgTask];
self.bgTask = UIBackgroundTaskInvalid;
}];

[[UploadSurveysManager sharedManager] uploadIfNeeded];
}
}


В Info.plist проекту необхідно вказати Required background modes: «App downloads content from the network»
З більш детальним описом запуску процесів в бекграунді можна ознайомитися тут:

developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH5-SW6

Важливо пам'ятати, що завдання в бэкгрунде мають обмеження за часом виконання. Для того щоб ефективно використовувати завантаження в бекграунді, її необхідно виконувати невеликими порціями і зберігати поточний стан, щоб відновити відправку при наступному запуску background task. Для задоволення цих обмежень ми обробляємо відправку оглядів по черзі. Спочатку окремо відправляються фотографії, що відносяться до огляду, а потім – спеціальний запит зі списком ідентифікаторів фотографій, що зв'язують їх з оглядом за відповідним завданням. Тільки після цього огляд вважається відправленим.

4.2. Оптимізація мобільного трафіку
Для економії мобільного трафіку в додатку реалізована перевірка типу інтернет-з'єднання. У налаштуваннях програми можна включити опцію «Не передавати дані по стільникового зв'язку в автоматичному режимі». Коли ця опція включена, інформація щодо проведених оглядам буде вирушати на сервер тільки при підключенні смартфона до мережі Wi-Fi. Крім того, можна включити відправку по стільникового зв'язку для окремого договору.

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

Висновок
Ось так завдяки нам, автовласники отримали можливість оформити КАСКО максимально легко.

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


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


До нових зустрічей!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.