Очаквания и реалности в CRM проектите. Последни развития Сурова реалност: Конфликт на интереси

Марин Восканян
Олга Мелник

Първото нещо, което помни един ИТ мениджър, когато става въпрос за автоматизация на продажбите, е внедряването на CRM система. Наистина, по целия свят е натрупан огромен опит в използването на CRM системи в процеса на продажби. Опитът обаче не винаги е положителен. Опитваме се да анализираме положителните и отрицателните страни на проекти за внедряване на CRM системи.

Внедряването на CRM обикновено има специални очаквания. Все пак става въпрос за продажби, получаване или неполучаване на директен доход. Най-често един от трите сценария тласка компанията към трудно решение за внедряване на CRM:

  • възникването на кризисна ситуация: мениджърът напусна и „открадна“ клиенти, рязък скок на конкуренцията, ниска събираемост на дълговете и е необходимо да се контролира информацията и да се систематизира дейността на служителите;
  • бързо развитие на бизнеса (или необходимост от развитие), което не може да бъде продължено „по стария начин“ и компанията изисква автоматизация на рутинни операции, контрол на ефективността, събиране и трансфер на знания;
  • корпоративен стандарт, който трябва да се следва, повишавайки инвестиционната привлекателност на бизнеса чрез консолидиране на клиентската база.

Експертите от доставчика на ИТ услуги Sputnik Labs подчертават именно тези ситуации като най-типични за Русия и в същото време отбелязват, че повече от половината клиенти дори нямат нито един клиентски регистър. Като цяло компанията клиент очаква от внедряването на CRM най-малко да възстанови реда, да намали зависимостта от конкретни мениджъри и като максимум да увеличи продажбите, за предпочитане експоненциално.

Да, успешно функционираща CRM система ви позволява да систематизирате информация за клиенти и контрагенти, както съществуващи, така и потенциални (фиг. 1), за да създадете единен информационно пространствои предотвратяване на загуби и изтичане на клиентски данни в резултат на съкращения и ротация на персонала. Ето мнението на ръководителя на една от руските компании: "CRM е абсолютно необходимо и полезно нещо за всеки търговски отдел. Дори най-простата автоматизация и установяването на основен ред в клиентската база дава икономически ефект, прави бизнеса по-прозрачен и устойчив. Ако е възможно да се внедрят по-сложни маркетингови и аналитични и CRM функции за управление, компанията значително повишава ефективността си."

Когато обаче става въпрос за въздействието на CRM върху растежа на продажбите, не е толкова просто. Разбира се, оценките за възможната възвръщаемост на инвестициите в CRM са пряко свързани с ефекта от ръста на продажбите. Някои световни статистики показват, че чрез внедряването на CRM се постигат:

  • намаляване на цикъла на продажба средно с 10-15%;
  • увеличаване на процента на спечелените транзакции с 5-10%;
  • увеличаване на процента на задържане на печеливши клиенти с 5%;
  • намаляване на времето за изпълнение рутинни операциис 25-30%;
  • увеличаване на средната доходност на сделките с 15-20%;
  • повишаване на точността на прогнозиране на продажбите до 99%;
  • намаляване на разходите за продажби, маркетинг и последваща поддръжка на клиенти с 10-15%;
  • увеличаване на процента на кръстосани продажби, включително чрез отдела за поддръжка на клиенти с 5-10%;
  • повишаване на ефективността на маркетинговите кампании с 5-7%.

В резултат на такава статистика се нарича приятна цифра: „рентабилността на средния CRM проект е от 200 до 400% в рамките на две до три години“. Не всички обаче са съгласни с това. Шестгодишният опит на изпълнителния директор на Vipro Олег Сковородников с различни CRM дава малко по-различна картина. Според него няма пряка връзка между подобренията в продажбите и внедряването на CRM. Олег Сковородников изброява следните като очаквани, но неоткрити ефекти.

1. Увеличаване на продажбите."Не беше открита пряка връзка. Косвено продажбите се увеличават поради факта, че мениджърите работят по-ефективно и бързо. Но не беше възможно да се докаже това с числа."

2. Подобряване качеството на услугата."Ние също не забелязахме пряка връзка. Служителите, които обслужваха и продаваха добре преди внедряването на CRM, продължиха в същия дух. Невежите и невнимателните останаха такива след внедряването на CRM. Но е много удобно, ако служител отсъства или уволнен - ​​в тези случаи CRM е просто незаменим, той не подобрява качеството, но създава самата възможност за услуга."

3. Увеличаване броя на повторните покупки, повишаване на лоялността на клиентите, закупуване на допълнителни стоки и услуги. "Всичко това е изцяло заслуга на мениджърите. Никой CRM няма да ги замени, но косвено помага за постигането на тези цели."
Що се отнася до друг наболял проблем - сигурността на данните, той също не се решава с реалното внедряване на CRM система. "Например, директорът по разработката беше уволнен - ​​коментира Олег Сковородников. - Той имаше достъп до клиентската база данни. Забравиха да го деактивират. Пет минути преди да си тръгне, мъжът експортира клиентската база данни и я изпрати на себе си у дома." Пощенска кутия. Като цяло, ако в редовете ви се появи нелоялен служител, CRM може да му помогне да направи нещо лошо за вас." Не трябва да забравяме, че появата на CRM в една компания не намалява, а увеличава броя на възможните заплахи и изисква адекватни и по възможност превантивни мерки от ИТ службата

Въпреки известен скептицизъм, търсенето на CRM системи в Русия се увеличава, според различни оценки, с 50-100% годишно. Основно активни са секторът на услугите, финансовият сектор, ИТ, телекомуникациите и търговските компании. По правило руските компании искат гъвкаво решение за своите процеси. Въпреки че често има случаи, когато, зачитайки опита, натрупан от реномиран производител на CRM решения, една компания реши да промени своите бизнес процеси, вместо да направи сериозни промени във функционалността на CRM системата.

Освен това се търсят решения, които осигуряват фронт-офис и бек-офис интеграция и интегрирани ERP/CRM системи. Факт е, че до 60% от разходите за внедряване на CRM система са разходите за интеграция със съществуващите CIS. И това не е изненадващо: CRM решение, отделено от ERP система, остава функционално незавършено. Без нормален бек офис възникват пропуски в бизнес процесите на компанията – например при прехвърляне на поръчка за изпълнение или издаване на фактура.

Провали на CRM проекти

Статистиката (според Gartner Group, Cap Gemini Ernst & Young и Peppers & Rogers Group) за CRM проекти на Запад е тъжна - от 50 до 80% от внедряванията в крайна сметка не отговарят на очакванията. Не се знае точно какъв е този процент в Русия, но едва ли ще е по-малко. Защо това се случва? Най-трудният случай е невъзможността за реализиране на проект в условията на съществуващата корпоративна култура, липсата на подходящо ниво на структуриране на бизнес процесите, което да позволи тяхната автоматизация (липса на регламенти, вътрешни правила за извършване на операции). А също и липсата обратна връзкамежду работната група за внедряване и предвидените потребители на системата в процеса на формулиране на списък от функционални и други изисквания към системата.

Често срещана грешка е поставянето на технологията „пред“ на стратегията. CRM се прилага, когато целите, процесите и структурите все още не са формулирани. Налична е само „мисия“, напомняща за историческите призиви на ЦК на КПСС „да работим по-добре“. Инсталирането на CRM приложения става преди компанията да е претърпяла необходимите организационни промени за прилагане на ориентиран към клиента подход. Освен това много хора искат да приложат всичко наведнъж. Според Андрей Павлов, управляващ партньор на FB Consult, съществува някакъв мит: колкото повече функционалност, толкова по-добре: както „в резерв“, така и „за проба от работа“. С този подход се образува „черна дупка“ за пари и усилия: ресурсите се разпръскват, за да се получи максимума функционалности по този начин създава непотърсен технологичен излишък. В същото време, вместо поетапен подход към трансформацията, задачата е да се трансформира целия клиентски бизнес „в една стъпка“: структуриране на клиентската база, диференциране на офертите, индивидуализиране на комуникацията и персонализиране на изпълнението.

Има и класически грешки - липса на необходимото внимание от страна на висшия мениджмънт, грешки при планирането, проблеми с координацията между отделите и отделите в компанията. В някои случаи, с вече внедрена CRM функционалност, компаниите не са в състояние да осигурят ресурси за разработената CRM стратегия и да извършат необходимите организационни промени.

Компанията Alfastrakhovanie, където работи системата SalesLogic CRM, отбелязва като необходими условия за успеха на внедряването на CRM силната воля на ръководството на отдела за продажби и неговия надзор на проекта, достатъчността на вътрешните ресурси за поддръжка на системата и в допълнение желанието на самите продавачи да приемат новите правила на играта или по-скоро въвличането им в нова „игра“. Известно е, че специфичен и остър проблем за CRM е до голяма степен съпротивата на самите мениджъри по продажбите. Те с основание го виждат като заплаха както под формата на засилен контрол върху тяхната работа, така и под формата на загуба на собствената им стойност като носител на знания за клиентите. Често се случва мениджърите да нямат достатъчно умения или време, за да анализират сериозно отношенията с клиентите, използвайки всички налични инструменти и да изградят „фуния за продажби“.

Може да има и функционални и технологични причини: системата просто е неудобна за използване за конкретни задачи. В резултат на това, вместо в работен инструмент, той се превръща в смущаващ фактор. Персоналът започва едновременно да поддържа списъци на своите клиенти в Excel файлове или по друг начин. Според ИТ мениджъра на един от големите руски клиенти, който има опит в внедряването на SalesLogix през 2001-2003 г., много руски доставчици на ИТ услуги започват работа с приятните думи „Кажете ми какво и как искате и ние ще автоматизираме всичко .” Тогава започва вълна от консултантска дейност, а резултатът е само хартия. И в резултат се предлага или пакетно решение (евтино, но бързо), или най-интегрираното решение, с почти целия наличен софтуер в компанията (ще бъде красиво, но скъпо и ще свърши ли?).

Как да избегнем провалите?

Андрей Павлов смята, че при внедряването е много важно да се стремим да получим уникално бизнес решение, което да даде на компанията неподражаемо конкурентно предимство. Трябва да подчертаете функционалността, от която вашите бизнес потребители наистина се нуждаят, и да се опитате да я приложите, като избягвате функционално излишък. Успехът на един минималистичен проект се осигурява от видимостта на резултата с разумни усилия. След това можете да се движите на същите етапи. Това може да помогне и в един особено важен въпрос - поддържане на интереса на ръководството към проект, който продължава няколко месеца.

„Това, което е необходимо, е фокусиран и прагматичен подход, при който бизнесът първо влага значителни усилия и време, за да идентифицира точно онези бизнес процеси, които ще донесат ползи, като използват съществуващите предимства или решават оперативни проблеми на „предния офис“. „какво“ и не „на какво“ се изпълняват определени функции“, отбелязва той и препоръчва да се избере „критична връзка“ за стартиране - стратегически важна задача, която може да бъде изпълнена без много стрес. Такива връзки може да са достатъчни сред „нискотехнологичните“ инициативи. Вярно, практиката показва, че ако дръпнеш едно звено от системата, неизбежно засягаш много други звена... Това е цяло изкуство - да избереш звено, което е съществено, но не много преплетено с други.

Излишъкът от функционалност, прекомерното разчитане на технологията като универсална панацея води до факта, че в работата на мениджърите се въвежда логика на действие, която е чужда и неразбираема за тях. Според Андрей Павлов има смисъл да се раздели задачата на две подзадачи: да се въведе в системата само логика, която е разбираема за топ мениджърите, като се вземат предвид текущите организационни промени. И всички останали потребители трябва да бъдат „доволни“ чрез актуализиране на опростени, но ефективни „добавки“.

Що се отнася до работата с персонала на отдела за продажби по време на прехода към нова система, по-голямата част от мениджърите твърдо заемат много твърда позиция: принуждават, наказват, глобяват. Във всеки случай е необходимо да се гарантира, че хората работят по новите правила всеки ден. Според Вадим Дозорцев, директор на консултантската компания Berner & Stafford, без това няма да може. Понякога все още чувате за по-конструктивен подход, основан на собствения интерес на служителите да увеличат своята производителност. Успешно се използват както чисто технологични методи, така и съчетанията им с организационни. Продавачът получава заплата, пропорционална на броя изпълнени договори. Споразумение не може да бъде сключено без попълване на определени формуляри в CRM. Разбира се, това може да стане един час непосредствено преди предаване на договора за подпис, но подобни неща могат лесно да се проследят чрез системните логове. И вече са глобени за това.

Има и други организационни находки. Както показа практиката на внедряване на системата MetodiX CRM в Руската банка за развитие, поддръжката на потребителите по време на внедряването е много важна. В този проект екип от специалисти по внедряване присъстваше на работните места на потребителите всеки ден в продължение на месец, наблюдавайки изпълнението на процесите и бизнес правилата, записвайки тесните места в процесите и желанията на потребителите. Въз основа на това бяха генерирани заявки за промени в процесите. Според представители на RBR, „Наличието на такъв екип премахва шока от потребителите по време на адаптацията към работа в системата.“

Ролята на проектния екип в проекта за внедряване на CRM система, както във всеки друг ИТ проект, е много важна. Желателно е той да не се променя и да е единен: бизнес звена, собствен ИТ отдел и консултант-доставчик на решение, всеки със своите фиксирани права и отговорности. Адекватни на ресурсите времеви рамки, оперативно наблюдение на случващото се, контрол на реалните резултати поне веднъж на всеки три месеца – клиентите говорят за всичко това на конференции като за ценен опит, натрупан с кръв и пот. И изглежда - азбуката на управлението на проекти...

И накрая, малко за цената на проектите за внедряване на CRM системи. Според Insight Technology цената на CRM проект се разпределя, както е показано на Фигура 4. Въпреки това, Павел Черкашин от Sputnik Labs предупреждава: „Според статистиката скритите разходи възлизат на 200-500% от първоначалната цена на проекта. ако получите съотношението други, проверете дали не сте забравили нещо..."

Сурова реалност: Конфликт на интереси

Анализирайки своя опит в внедряването на SalesLogix през 2001-2003 г., един от големите руски клиенти посочи конфликт на групи на интереси в проекта CRM. За управлението на клиента CRM е софтуер, който „ще реши всички наши проблеми“, „крайният срок за внедряване е вчера“. В същото време напълно се пренебрегва, че CRM решението не е толкова софтуер, колкото концепцията за нова връзка с клиента, поддържана от софтуер. Ръководството казва: „Ще наблюдаваме как ИТ внедрява системата. Ако не се получи, IT ще бъде отговорен за всичко. Продавачите са сигурни, че нямат нужда от системата, „ние вече знаем всичко за клиентите“, „те искат да ни контролират отново“. Анализаторите искат системата да позволява повече отчети, а от продавачите ще се изисква да въвеждат много различна информация в нея. (Известно е, че събирането на големи обеми информация не прави непременно системата по-управляема.) А общият подход на бизнес клиента се оказва: „Прави каквото ти се каже – ние знаем най-добре и няма да променяме съществуващите бизнес процеси." Нека добавим към това: собственият ИТ отдел на компанията е уверен, че може да направи всичко сам и като цяло системата собствено развитиеби било много по-добре. В резултат на това проектът се забавя под предлог за несъответствие на софтуера с ИТ възможностите, ИТ платформата, условията на работа, сигурността и т.н.

Обработка на адреси ( UrlRewrite) се използва, за да може скриптът да отговаря не само на своя физически адрес, но и на всеки друг посочен адрес. Например, можете да зададете настройките за обработка на адреси, така че скриптът във файла /fld/c.phpотговаряйки на адреса

/fld/c.php?id=15

също отговори на адреса

/каталог/15.php

Адресът, на който ще отговаря скриптът, не трябва да съществува физически на сървъра. Ако физически съществува такъв адрес, скриптът ще бъде извикан на този адрес. В този случай системата за обработка на адреси няма да стартира.

Правила за обработка

Правилата за обработка на адреси се конфигурират отделно за всеки сайт и се съхраняват във файла в основата на сайта urlrewrite.php. Файлът съдържа масив $arUrlRewrite, всеки запис на който е правило за обработка на адреси. Файл urlrewrite.phpима следната форма:

"#^/gallery/#", "RULE" => "", "ID" => "bitrix:photo", "PATH" => "/max/images/index.php",), array("CONDITION " => "#^/forum/#", "ID" => "bitrix:forum", "PATH" => "/forum/index.php",), array("CONDITION" => "#^/ index/(+)/(+)/#", "RULE" => "mode=read&CID=$1&GID=$2", "ID" => "bitrix:catalog.section", "PATH" => "/newforum /index.php",), array("CONDITION" => "#(.+?)\\.html(.*)#", "RULE" => "$1.php$2",),); ?>

Всяко правило трябва да съдържа условие за изпълнение на правилото, което е уникално в сайта. Условието за изпълнение се записва в ключа " СЪСТОЯНИЕ" масив и е Perl-съвместим модел на регулярен израз. Например условието:

"УСЛОВИЕ" => "#^/индекс/(+)/(+)/#"

показва, че това правило трябва да се прилага към всички адреси, които започват с поднизове на формуляра:

/индекс/<число>/<число>/

Правилото може да съдържа адреса на физически съществуващ скрипт, който ще бъде свързан, когато условието бъде изпълнено. Този адрес е записан на ключа " ПЪТЕКА". Например, ако правило е регистрирано в системата за обработка на адреси:

Array("CONDITION" => "#^/gallery/#", "PATH" => "/max/images/index.php",)

и потребителят поиска страницата:

/галерия/38.php

което не съществува физически, тогава системата за обработка на адреси ще свърже скрипта:

/max/images/index.php

Правилото може да съдържа заместващо правило, което се записва в ключа " ПРАВИЛО". Ако правилото за заместване е зададено, тогава адресът на реален скрипт на добавка се формира чрез заместване на условието за изпълнение (шаблон на израз) с конкатенация чрез регулярен израз физически път(ключ " ПЪТЕКА") и правила за замяна (ключ " ПРАВИЛО"). Например, ако правило е регистрирано в системата за обработка на адреси:

Array("CONDITION" => "#^/index/(+)/(+)/#", "RULE" => "mode=read&CID=$1&GID=$2", "PATH" => "/newforum/index .php",)

/индекс/5/48/

$url = preg_replace("#^/index/(+)/(+)/#", "/newforum/index.php?mode=read&CID=$1&GID=$2", "/index/5/48/") ;

и скриптът ще бъде свързан:

/newforum/index.php?mode=read&CID=5&GID=48

Ако правило е регистрирано в системата за обработка на адреси:

Array("CONDITION" => "#(.+?)\\.html(.*)#", "RULE" => "$1.php$2",)

и потребителят поиска страницата:

/about/company.html?show

след това за генериране на адреса на скрипта, който ще бъде свързан, кодът ще бъде изпълнен:

$url = preg_replace("#(.+?)\\.html(.*)#", "$1.php$2", "/about/company.html?show");

и скриптът ще бъде свързан:

/about/company.php?show

Правилото може да съдържа името на компонента, който е създал правилото. Това име е написано на ключа " документ за самоличност". При автоматично повторно създаване на файла с правила urlrewrite.phpЧрез инструментите на административната част на сайта се пресъздават само правила, за които е попълнен ключът " документ за самоличност". Тези правила са пресъздадени въз основа на анализа на физически файлове в папката на сайта. Правила с празен ключ " документ за самоличност" Когато файлът се създава автоматично, правилата не се променят.

Свързване на система за обработка на адреси

Преди да го използвате, системата за обработка на адреси трябва да бъде свързана към сайта. За да направите това ви трябва:

  • ако вашият уеб сървър е конфигуриран да обработва грешки 404 (например за Apache директивата е зададена ErrorDocument 404 /404.php), тогава трябва да промените файла /404.php, като вмъкнете командата в самото начало на файла: include_once($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/urlrewrite.php");
  • ако използвате модул за Apache mod_rewrite, тогава в неговите настройки можете да посочите (например във файла .htaccess): RewriteEngine On RewriteCond %(REQUEST_FILENAME) !-f RewriteCond %(REQUEST_FILENAME) !-l RewriteCond %(REQUEST_FILENAME) !-d RewriteCond %(REQUEST_FILENAME) !/bitrix/urlrewrite.php$ RewriteRule ^(.*)$ /bitrix/urlrewrite .php [L]

Поддръжка на компонент 2.0

Когато добавяте CNC-активиран компонент към страница (" четим от човека URL адрес") (ако файлът е записан с помощта на API), автоматично се създава правило за обработка на адреси. Ако страницата не е създадена с помощта на API, а например е написана чрез FTP, тогава трябва да създадете отново правилата ( бутон на лентата с инструменти на страницата за настройка на правила за обработка на адреси) .

Поддръжката на CNC е активирана в компонент с помощта на предварително дефиниран входен параметър SEF_MODE. Освен това в предварително зададения входен параметър SEF_FOLDERПапката, в която се изпълнява компонентът, е инсталирана. Папката може да е виртуална (т.е. може да не съществува физически). При запазване на страница с поставен върху нея компонент, превключен в режим CNC (параметър SEF_MODEравно на Y), чрез стандартен интерфейс се създава правило за обработка на адреси, както следва: в ключа за условията на приложението на шаблона (" СЪСТОЯНИЕ") записва регулярен израз, получен от папката в параметъра SEF_FOLDER, в ключа " документ за самоличност" името на компонента се записва в ключа за пътя (" ПЪТЕКА") се записва физическият адрес на страницата.

Например нека компонентът " bitrix:каталог“, публикуван на страницата /fld/c.phpи връзката му изглежда така:

$APPLICATION->IncludeComponent("bitrix:catalog", "", Array("SEF_MODE" => "Y", "SEF_FOLDER" => "/mycatalog/", "IBLOCK_TYPE_ID" => "каталог", "BASKET_PAGE_TEMPLATE" = > "/personal/basket.php",));

След това при запазване на страницата /fld/c.phpще бъде добавен запис към системата за обработка на адреси:

Array("CONDITION" => "#^/mycatalog/#", "RULE" => "", "ID" => "bitrix:catalog", "PATH" => "/fld/c.php")

Така при заявка на адреси, започващи с реда /моят каталог/, скриптът ще бъде свързан /fld/c.php. В този скрипт исканият адрес може да бъде анализиран и необходимите действия могат да бъдат извършени.

Вижте също

  • в основния курс за администратор.
  • в курса Разработчик на рамка на Bitrix.

второто правило няма да работи за „вашия“ адрес (например /about/news/55/), т.к. първият, универсален, работи за този адрес. Тоест в началото на файла трябва да се пишат по-точни правила, а в края – обобщени.

в същия файл създайте условие:

Код
RewriteEngine On RewriteCond %(HTTP_HOST) ^olddomain\.ru$ RewriteRule ^(.*)$ http://newdomain.ru/$1 RewriteCond %(REQUEST_FILENAME) !-f RewriteCond %(REQUEST_FILENAME) !-l RewriteCond %(REQUEST_FILENAME) !-d RewriteCond %(REQUEST_FILENAME) !/bitrix/urlrewrite.php$ RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]

"Bitrix", 2001-2019, "1C-Bitrix", 2019

Нека да създадем информационен блок в BITRIX, да покажем списък на създадените елементи с помощта на компонента bitrix:news.listи направете страницата с подробности за елемента компонент bitrix:news.detail

Задължителни полета за попълване:
Раздел с информационен блок

Раздел Достъп

Извеждане на елементи за информационна сигурност

За да покажете елементи на информационен блок, използвайте bitrix:news.list в index.php

IncludeComponent("bitrix:news.list", "tour", // template array("IBLOCK_TYPE" => "content", // тип информационен блок "IBLOCK_ID" => "1", // ID на информационен блок "NEWS_COUNT" => "10", // брой показани елементи "INCLUDE_IBLOCK_INTO_CHAIN" => "N", "ADD_SECTIONS_CHAIN" => "N", "SET_TITLE" => "N", "PROPERTY_CODE" => array(0 => " NAME ", // активирайте свойството от информационния блок),), false); ?>

Списък на всички възможни параметри за компонент

Ако е необходимо филтриране, има параметър FILTER_NAME. Над извикването на компонента bitrix:news.list създаваме глобална променлива с параметър за филтриране.

1); // Тези елементи, чието свойство OLD е зададено на 1, няма да бъдат показани ?>

и в bitrix:news.listпремине филтъра.

"FILTER_NAME" => "arrFilter",

Настройка на urlrewrite

В urlrewrite.php трябва да посочите параметри за обработка на URL.

"#^/tury/(.*)/.*#", // Обработка страница с подробности"RULE" => "ELEMENT_CODE=$1", "ID" => "bitrix:news", "PATH" => "/tury/detail.php", "SORT" => 100,), масив ("CONDITION" => "#^/tury/#", // Обработване на главната страница на раздела "RULE" => "", "ID" => "bitrix:news", "PATH" => "/tury/index. php", "СОРТ" => 100,),);

Извеждане на страница с подробности

За показване на подробна страница в детайл.phpизползвани bitrix:новини.послед. Минимален набор от параметри за обаждане:

IncludeComponent("bitrix:news.detail", "tour", // template Array("IBLOCK_ID" => "1", // ID на информационен блок "IBLOCK_TYPE" => "content", // тип информационен блок "ELEMENT_CODE" => $_REQUEST["ELEMENT_CODE"], // параметър на предадената страница "INCLUDE_IBLOCK_INTO_CHAIN" => "N", "ADD_SECTIONS_CHAIN" => "N", "SET_BROWSER_TITLE" => "Y", "SET_META_DESCRIPTION" => " Y" , "SET_TITLE" => "Y", "ADD_ELEMENT_CHAIN" => "Y", "PROPERTY_CODE" => array(0 => "NAME", // включва свойство от информационния блок),), false); ?>

Извеждане на изображения от свойствата на информационния блок

Показването на снимки, които са в свойствата на елемент за защита на информацията, не е толкова просто. В масива с данни на подробната страница ще видим само идентификационните номера на снимките, а не пътя до тези файлове. Следователно във файла result_modifier.php е необходимо да се обработи изхода на тези снимки.

В папката шаблон, във файла резултат_модификатор.phpпреминаваме през масива от снимки:

$photo) ( $photo_small = CFile::ResizeImageGet($photo, array("width"=>200, "height"=>200), BX_RESIZE_IMAGE_PROPORTIONAL, true); $photo_original = CFile::ResizeImageGet($photo, array( "width"=>800, "height"=>800), BX_RESIZE_IMAGE_PROPORTIONAL, true); $arResult["PHOTOS"] = Масив ("original" => $photo_original["src"], "small" => $photo_small ["src"],); )

И във файла template.phpВече показваме и самите снимки:

"> ">

Системата PayCash се превърна в търговски отговор на недоверието към дистанционното плащане на стоки с кредитни карти. Проектът е разработен от Tavrichesky Bank и групата компании Alkor-Holding и е предназначен да подпомага купувачите и продавачите на електронни магазини (от предоставяне на система за онлайн плащане до хостване на онлайн магазини). Потребителите на PayCash не се нуждаят от кредитна карта. Това е отворена платежна система, всяка банка може да се свърже с нея. Плащанията в интернет са анонимни, като потребителят получава акаунт в системата PayCash, от който може да извършва всякакви безналични плащания. Разбира се, преди това трябва да откриете сметка в банка, която поддържа системата PayCash, след което кредитираните средства ще бъдат конвертирани в „електронни пари“. Плащането се извършва например по следния начин: посетител на виртуален магазин кликва върху бутона „Плащане чрез PayCash“; данните за поръчката се прехвърлят в Центъра за приемане на плащания; Продавачът получава потвърждение, заверено с електронен подпис. След това Центърът за плащане поема задължения към магазина и превежда пари в банката, посочена от продавача, в размер на плащането PayCash. Не изглежда ли като надеждна акредитивна форма на плащане? Разбира се, за използване на системата се начислява комисионна в размер на 1-3% от сумата на плащането (в зависимост от условията за влизане в системата).

За купувача използването на системата PayCash се свежда до инсталиране на програма за портфейл на компютъра и извършване на финансови транзакции от нея. „Портфейлът“ съдържа ключ за генериране на електронен подпис, който се използва за „маркиране“ на всеки документ, изпратен от програмата. Програмата за портфейл, за щастие, не използва алгоритми за обвързване с компютърен хардуер (например серийния номер на процесор Pentium III), така че „портфейлът“ може да бъде безболезнено прехвърлен от компютър на компютър.

ПОМОЩ

Системата за електронни разплащания ASSIST е проект, който дава възможност за авторизация и обработка на плащания, направени с кредитни карти в реално време. Освен това плащането може да се извърши, да речем, от сметката на клиента при интернет доставчика. При прехвърляне на поверителна клиентска информация (данни за кредитна или депозитна карта), плащането през споделената мрежа се извършва чрез защитена връзка с помощта на протокола SSL 3.0. Авторизацията и обработката на кредитни карти се извършват в системата CyberPlat на Platina Bank. Информацията за данните на картата, разбира се, остава поверителна и не се предоставя дори на директния продавач. Към онлайн магазина се изпраща само потвърждение за плащане, заверено с цифров подпис с 512-битов ключ за криптиране.

Системата ASSIST се използва от десетки онлайн магазини и информационно-консултантски ресурси. Един от най-известните „адепти“ на системата е онлайн магазинът „oZon“ (http://www.o3.ru) - друг номиниран за Националната интернет награда на Intel.

Доставка.Ru

“Dostavka.Ru” е ако не феномен, то изключително успешен търговски проект в руската част на интернет. Бизнес моделът е изграден на принципа на куриерска доставка на офис оборудване, комуникационно оборудване и информационни услуги (осигуряване на достъп до Интернет) с плащане в брой на място. Работи по-бързо и по-надеждно от механизмите за дистанционно плащане и доставка, особено като се има предвид „прецизността“ на нашата поща. Обхватът на стоките и услугите по принцип е ограничен: консолидираната ценова листа включва малко повече от хиляда позиции. Магазинът обслужва само Москва в рамките на Московския околовръстен път. Продуктите се доставят безплатно: било то касета за принтер, монитор или копирна машина. Цените не са много по-ниски от средните за Москва, но, разбира се, има по-малко главоболия. Виртуалният сървър, към който се получават поръчките, работи на оборудването на интернет доставчика Zenon N.S.P. Delivery.Ru, между другото, стана един от първите магазини, които предоставиха на своите посетители безплатен достъп до Интернет (естествено, само за посещение на неговия сървър).

Проектът беше стартиран само от трима души, които имаха два компютъра и един модем - точно като в задграничните истории за създаването на "гаражни" компании в Силиконовата долина. Създаването на магазина отне фантастично кратко време – два месеца. В момента в офис дейността са заети около 20 служители. Обикновено магазинът обслужва 50–70 поръчки на ден, но е в състояние да „смила“ няколко пъти повече заявки със систематично разширяване на персонала (и, разбира се, с подходящо търсене).

Какво е необходимо, за да расте? Как да разтопим леда на недоверието, което исторически се е развило по отношение на интернет търговията? „Да, като цяло, няма рецепта“, отговаря Андрей Хромов, ръководител на проекта в Dostavka.Ru. „Нашата задача е да гарантираме, че клиентът използва нашите услуги поне веднъж.“ Само личният успешен опит помага да се оцени удобството на онлайн пазаруването. Освен това доставката трябва да се извърши за няколко часа или дни и през цялото това време парите остават под надеждния надзор на законния им собственик. Това не са дни на тревожно чакане след извършване на банков превод.

Усеща ли Dostavka.Ru негативното влияние на правните пропуски, регулиращи работата на онлайн магазина? Според официалната реакция на ръководителите на проекта, те се чувстват доста комфортно в рамките на съществуващото законодателство. Според Андрей Хромов само тези видове интернет търговия изискват определено законодателство, в което продавачът и купувачът никога не се срещат. Например при плащане с кредитни карти. Рискова е и търговията със стоки, за които се изисква специално разрешение (продажба на алкохол, тютюневи изделия, бижута и др.). Web for Dostavka.Ru е просто красива витрина, удобен и евтин инструмент за събиране на поръчки. По-нататъшната организация на работа с клиента не се различава много от някоя пицария. „Имаме обикновен магазин“, потвърждава Хромов. „Ние работим по „физически“ правила, а не по виртуални.

Сред трудностите, пред които е изправена онлайн търговията, Хромов отбеляза липсата на установена B2B схема за онлайн магазини.

Megashop.Ru

Уеб магазинът Megashop.Ru е специализиран в продажбата и доставката на компютърна техника. Доставката се извършва само в Москва, като плащането може да се извърши в брой, с кредитни карти на всички основни платежни системи и чрез превод в рубли. Можете да „превъртите“ картата в машина за фиш по време на доставката. Освен това магазинът се задължава да върне парите, дори ако поръчката вече е действително платена, но купувачът я е отказал, макар и без обяснение (което е напълно в съответствие със „Закона за защита на правата на потребителите“).

Според официалната информация от разработчиците на проекта, създаването на магазина е отнело шест месеца и 100 хиляди долара, Рустем Ахияров, представляващ Megashop.Ru, също обясни, че промотирането на магазина струва няколко пъти повече. След като разгледа възможностите за хардуерна организация на проекта, компанията не постави сървъра в своите помещения и постави скъп канал. В резултат на това се спряхме на опцията за колокация - поставяне на сървъра на сайта на доставчика.

„Бариерата на недоверието към онлайн пазаруването е просто форма на здравословен човешки консерватизъм“, казва Рустем Ахияров. Единственият начин да го преодолеете е да осигурите удобни условия на плащане, ниски цени и богат асортимент. Уеб хостингът на витрина очевидно помага за намаляване на разходите във всички разходни центрове.

Ръководството на Megashop.Ru не се оплаква особено от пречките от несъвършеното законодателство. Има трудности от напълно „ежедневен” характер – следствие от нецивилизоваността на пазара. „Ситуацията стига до абсурд: не всички доставчици на компютърна техника могат да предоставят информация за наличността и цената на стоките в необходимия формат“, коментира г-н Ахияров. - Мениджърът по продажбите дава всичко от себе си, за да прави продажби, но всичко, което има, е ценова листа, предназначена за формат А4. Системният програмист на тази компания може да прекарва часове ден след ден, обяснявайки защо е „невъзможно“ да получи само списък със стоки с цени в две колони, въпреки че за него това са 5 минути работа.“

PAGERGATE.RU
SMS.GATE.RU

Много потребители на пейджъри и GSM мобилни телефони са запознати с комуникационните портали http://www.pagergate.ru и http://sms.gate.ru. От тези уеб сайтове можете да изпращате съобщения до пейджъри и GSM клетъчни телефони, обслужвани от 400 оператора в Русия и страните от ОНД.

Според Алексей Виноградов (координатор на проекта SMS.Gate.Ru), основната интензивност на проекта дори не беше в разработването и поддържането на услуги (това отнема 30% от времето), а в комуникацията с операторите и потребителите. По-голямата част от приходите на PagerGate идват от реклама (осигурена от интернет рекламната агенция Manifest). Но сега някои компании използват SMS услуги за търговски цели, за да уведомят своевременно своите служители. Услугите SMS към ICQ и ICQ към SMS ще бъдат пуснати в близко бъдеще. Освен това вече има услуги, които предоставят изпращане на съобщения до радиокомуникации чрез имейл (и обратно). В момента се подготвя услуга за работа с пощенски списъци (водят се преговори с голямо печатно издание и един от сървърите на пощенските списъци). За корпоративни клиенти се предоставят услуги като хостинг, организиране на предаване на съобщения чрез корпоративни уеб сайтове, специален SMS шлюз и др.

Разработчиците на проекта не са използвали никакво екзотично оборудване. Има сървър на “главната” телефонна централа М9 и втори резервен на друг сайт на доставчика. Хардуерът на SMS.Gate.Ru се състои от няколко различни GSM телефона и GSM терминала. Проектът всъщност се обслужва от четирима души: координатор (обща администрация, програмиране, комуникация с потребителите), системен инженер, специалист по маркетинг и реклама и лице, отговарящо за общите въпроси.

Публикации по темата