Modern Repair Service Organization and Overlooked Functions in ERP

Follow @ArtieBe
Many ERP (Enterprise Resource Planning) packages offer core support for PSA (Professional Services Automation) businesses, which often attempt to cover also repair service functionality. In reality, it is quite difficult to satisfy the wide range of business requirements in diverse industries with one standard service module available as one standard way of doing things. E.g., heavy machinery dealership service is very different from medical devices repair. Here are some of the key requirements - potential gaps I came across at similar businesses - worth examining before investing in ERP or LOB software to support business models relating to repair service of instruments. I am currently working on identifying enhancement customization approaches and ISV solutions for Microsoft Dynamics ERP customers in this area. If you would like to learn more, discuss or suggest solution, please feel free to contact me.

Tracing Service Object
Excellent repair servicing of expensive instrument will likely require ability to track transactions of the instrument and/or its parts in question by their unique serial numbers over full life-cycle of individual products. This may include tracking of where the product or its parts have left from production to reseller (own sales entity or distributor etc), further assembling operations, shipping to customer etc.
ERP will normally support rich tracking inventory items in a warehouse and even at the inter-company level of a global organization, but the same functionality might not be available for repair service items (sometimes called, service objects), which often belong to 3rd party organizations (customers, dealers etc.) or are leased and handled via separate framework or logic within ERP.

Repair Quotations
ERP will normally offer sales quotation function as part of CRM, sales or project functional areas. These will be integrated with inventory item master or new project creation.
Repair services will often deal with service objects, which belong to 3rd party organizations (customers, distributors etc) and not stored in own inventory records. Quotes will often be created based on inspection results of repair lines in service functional area. Entry of the same data on sales quote would cause additional double-entry effort and some level of disintegration with repair. Thus, adding quote functionality into repair area might be an additional need.

One Repair – Many Support Arrangements
One repair case of the whole instrument can include multiple support arrangements with different processing and segregation at transaction line level. For example, labor can be under service contract but spare parts are chargeable. One defect of the same instrument might be covered by sales warranty, another by service contract or simply chargeable repair. ERP standard package might not offer complete administration and tracking functions for a repair in case of such combined scenarios.

Service Contract Invoicing
While many ERP systems offer service contract functionality, consider how it is linked to finance, invoicing process and with various scenarios like cost and revenue recognition etc. Usually ERP project modules has this kind of link with finance and general ledger while additional integration and functionality might need to be established for service contracts.

Loaners
Upon instrument return for repair, it might be necessary to ship a loaner (temporary replacement) to the customer till the repair of original item is finished. Loaners could be company’s own stock and never sold to the customer but shipped to them. Such lending operations are not necessarily supported in many standard ERP systems. Furthermore, due to the high value of these instruments, in many countries they might be considered as fixed assets and thus handled differently than inventory stock. Some would also require conversion between both.

Intercompany Service Transactions
Larger global businesses engaging in repair services of instruments will likely organize their repair workshops in local and regional centers involving transactions among legal entities. For example, a company might choose to set criteria according to which minor repairs are done locally, e.g., at a country level, but more complicated ones - demanding more effort or specific expertise are sent to a regional repair center. This could involve shipping and receiving the repair service object belonging to customer and inventory parts from another subsidiary or factory. Furthermore, often mandatory transaction tracing by serial number and sharing of service order data among multiple companies can further reduce the standard fit levels of ERP package in question.

Damage Catalog
For a more efficient planning, management and solving equipment damages, many repair organizations choose to catalogue them and link to resource and operation planning. This classification means grouping at least the most frequent types of instrument damages, providing them with IDs, titles, descriptions, photos, solutions and other properties. Furthermore, required time, resources and location can be planned for each of the types per product, effort and workshop capacity planned in advance. If repair inspectors are to use the ERP system, it is likely that such functions would be requested.

Mobility
With the mobile taking over business processes, it is likely that mobile interface or apps will be requested by a modern repair service organization not only for the field service to connect to the service object data and update it, but also in-house. For example, many inspectors would rather use a mobile tablet interface to make photos and fill out a form than existing paper forms followed by entry into ERP table interface as it is often done today.

Single vs. Multiple Instance Global ERP: Case of Microsoft Dynamics AX 2012

Follow @ArtieBe
A quick summary of pros and cons for single vs. multiple ERP solution instances when planning to deploy a global ERP. Considerations are based on experiences with Microsoft Dynamics AX 2012 product. Advantages of one approach often reflect disadvantages in the second.

Single Instance Pros

• Cost benefits - potentially less investment required with lower TCO - one instance clearly requires less resources and lower ongoing cost than multi-instance.
• Simplified management - setup and processing of various master data and group's transaction data in same set of rules, (global address book, products), inter-company transactions, consolidation processing etc - by having all data and legal entities stored and managed within the same instance.
• Unlike in previous versions, with Microsoft Dynamics AX 2012 release, various standard AX localizations (different functionality per legal entity) are supported within the same instance and do not require additional deployments for supporting local legal requirements.

Single Instance Cons

• Maintaining potentially complicated dependencies and rules caused by modifications and configurations to meet diverse local and regional business specific requirements. Customization for one region or legal entity can have undesirable dependencies for others. Meanwhile, workarounds exist. For example, create a modification for regional enhancement, which determines the user's region and enables respective customizations in the legal entity he/she belongs to.
• Increased impact of maintenance or failures on all worldwide regions and users. If for any reasons, the production ERP instance shall be stopped for troubleshooting or maintenance, this can affect the whole worldwide users in all time zones.
• Database limitations - scaling out of Microsoft SQL server performance in large deployments and collations issues with storing text fields in different ways.
• Availability of network infrastructure to all worldwide users. Network latency and other network considerations for users in various locations are usually raised when considering single instance vs. multiple an may require additional validation before making the decision.

Multiple Instances Pros

• Easier to implement and maintain more complex modified solutions where such customizations and configurations for one region and legal entity can cause undesirable effects on others if handled within the same application instance. It is often considered better to separate these into instances.
• Mitigate the impacts from downtime risks or maintenance if production system should be turned down for a some time especially over multiple timezones. Industries like retail and other would not be able to afford long downtime of business critical system in one place for whatever reasons causing it in other regions.
• Solution to some database limitations - ability to scale out Microsoft SQL server to improve performance in large deployments and resolve potential collations issues by separate instance of database.

Multiple Instances Cons

• Higher investment and TCO caused by additional server licenses or subscriptions in ERP platform, staff (especially, for on-premise case), maintenance and more additional deployment environments (e.g., test, validation etc) required. 
  
• Additional complexity in modifying and maintaining cross-instance customizations since same code might need to be promoted and tested across diverse multiple application instances.
• Maintaining and processing cross instance data and rules is not so straightforward as in single instance. For example, consolidation processing would require additional steps with file exports. Master data integrity across companies might require additional steps or solutions. Master data management solution, such as, Microsoft SQL Master Data Services can be considered. Furthermore, if a company wants to implement a global BI & Analytic solution, this will affect the data warehouse and BI solution architecture.
• Lower impact of downtime since instances are separated.

Office 365の有効活用ための６つのアイデア

Follow @ArtieBe

顧客へのサービスする、様々なタスクを達成する、人と繋がるために今日の組織は益々高度な生産性とコミュニケーションツールを必要としています。ところが、企業にはパッケージの様々な能力及び利用できるサービスについて意識されてない可能性があります。高いROIを達成するためにビジネスとITの経営者は予めパッケージの使用を計画、促進したほうがいいのではないでしょうか。今回は、Office 365の有効活用方法を検討します。

ファイル送信ではなく、ドキュメントをクラウドで簡単に共有しましょう
Office 365ではドキュメント、フォルダーとファイルのアクセスの簡単なコントロール（編集と閲覧）方法が提供されています。これを利用するとユーザー同士で一つの保存場所でバーションを管理し、アクセス権のコントロールができます。加えて、メールボックスのメモリを減らすこともできるし、多くのメールの混乱を避けることも可能です。

他のアプリケーションとの連携
Office 365はその他のアプリケーションの高度な連携と使用事例が提供されています。例えば、LyncとSkype間でインスタントメッセージのやり取り、音声やビデオでの会話ができます。
Sales ProductivityというパッケージはOffice 365及びDynamics CRM Onlineを効率的な方法で結合します。連携シナリオの例は下記のとおりです。
⋆　Yammerの内部ソーシャルネットワーク利用で営業案件に関するチーム参加者のコラボレーションを改良
⋆　SharePointに基づいたCRMのエンティティに関するドキュメントの高度な管理
⋆　Exchange Onlineに基づいたEメールによる営業活動とカレンダーとの統合のサポート
⋆　Excelとのデータ統合（PC上とOffice Web Apps）
⋆　ダイレクト・メール・キャンペーン用のMicrosoft Officeの差し込み印刷
⋆　Excel、Power BIに基づいたデータ分析

自社に合ったプランに合ったプランの選択
Office 365は様々な組織の実際要件に対して幾つかサービスプランが提供されます。例えば、シフト勤務の人や店員は会社で席を持っていない、あるいは一台のPCを共用しています。Office 365のキオスク・プランはこのようなユーザーのコミュニケーションと協力を無駄な投資無しで改良できます。

新規リリーズを検討しましょう
Office 365は進化し、毎月新規の機能がリリースされるので、その新しいバリューを検討しましょう。過去の更新の例としてOffice Web Apps機能強化、iPad用のMicrosoft Office、メールボックスのサイズ増量等でした。

展開プロジェクトタイムラインとの利用調整
Office 365あるいはExchange Online、SharePoint等のコンポーネントの導入とマイグレーションは、リソース管理等の活動でプロジェクト管理とスケジュールを必要としています。新しいサービスを購入する時にその実際の展開能力を確認したり、おおよその計画を立てることは良いアイデアです。

無料トレーニングのリソース検討
何時でも新しいことが勉強できます。現在は、多くのOffice 365教材に無償でアクセスすることが可能です。英語ですが、こちらからアクセスできます。

Considerations for Implementing Dynamics AX in Japan - Renewed

Follow @ArtieBe
Back in July 2012, I published an article in Dynamics Community titled "Considerations for Implementing Dynamics AX in Japan". Couple of things have progressed since then and are now updated with this new posting.
Like any other country, Japan has some unique business practices and requirements. This article is to provide some insight into Japan specific considerations when implementing Dynamics AX or ERP software. We will examine functional, technical and project related requirements in general rather than looking into technical and setup details. This article is intended for key business users and project members as well as technical specialists who just need a quick reference about ERP system requirements in Japan. The article is not to cover all Japan specific ERP implementation requirements. These can differ case by case over various Dynamics engagements and industries. This article is based on the author’s experience form Dynamics implementations in Japan and Japanese companies in the region.

ERP Functional Requirements - Finance & SCM

Japanese UI and Business Documents
Japanese users would prefer Japanese language user interface (UI) instead of English. Business documents like invoices, delivery notes, accounting documents and various reports in domestic business would normally be requested in Japanese. Dynamics AX localization generally support this requirement.
The final layout of documents and customized functions will depend on company’s requirements since business documents are normally reviewed and adjusted for each organization rather than using “Out of the box” objects. Examples of this work include changing layout, adding logo, adding or removing fields etc. Unique to Japan and some East Asian countries is seal (hanko) graphics or box design required on business documents. Organization or user can ask for a red seal appearing on company address in a document.
While customizing forms, documents and reports to be viewed in multiple languages, it might be necessary to adjust the size of labels in order for layout to look nice in Japanese as well as English.

Consolidated Invoice
Consolidated invoice is one of the often mentioned country-specific requirements in Japan. This means consolidating more than one sales order with posted packing slips into one invoice as of consolidation date. Invoicing schedules can differ per agreement with customer. Consolidated invoice feature is supported in relation to sales orders in Dynamics AX. Invoice consolidation practice is also used in other countries than Japan.

T-Account Journal
T-Account journal is preferred form layout for many users in Japan when processing accounting transactions with debit and credit amounts. It allows user to enter debit and credit transaction in the same line. This requirement is normally supported in most of Japanese accounting packages (Glovia, NEC Explanner, Grandit etc.) and is part of Dynamics AX Japan localization.

Kana
Japanese language uses Kanji - adopted and modified Chinese characters. Phonetic guidance of these characters uses kana writing system. This requires additional fields on multiple forms for Kana names to provide correct pronunciation and meaning of Kanji. These fields are normally required on customer, vendor, and employee forms showing a person’s name.

Banking
In order to upload vendor payments into banking systems directly from Dynamics AX, all the major Japanese banks (Mizuho, Tokyo-Mitsubishi UFJ etc.) will require payment data files to be prepared according to Japanese Bank Association (JBA) bank format. Dynamics AX localization provides support for this function since version 4.0.
A payment fee extension was released recently and covers the scenarios where a bank payment fee can be calculated automatically. It considers both scenarios in Japan where the payment fee can be paid by the vendor or by the company.

Promissory Notes
Promissory note (bill of exchange) is a document that allows payment to be settled by specifying (promising) that another party will pay for the goods or services. Usually this 3rd party is a bank. Popularity of promissory notes seems to be declining in Japan due to low interest rates associated with this financial tool. Dynamics AX supports rich functionality for bill of exchange transactions. Recently electronic promissory note integration with bank account has been required by some companies while not yet supported with Dynamics standard functionality.

Rounding
It is possible to set up rounding of different types within the standard system including for JPY. Meanwhile, companies might want to set up rounding on specific criteria like customer base. Some Japanese ERP packages have functionality with different rounding types for the same transaction on sales details (lines) and collective invoice

Fixed Assets
It has been observed in the past that some companies used local packages, such as OBC Shokyaku Bugyo to handle fixed assets and integrated it into Dynamics AX. Lots of progress has been made in resent updates to better fit Dynamics AX fixed assets in Japan.  Dynamics AX 2012 R3 in its cumulative update 8 supports the Japan tax depreciation methods and legal ratios. The Japan fixed asset localization can offer capability of producing appended table 16 series and Form 26.
Consumption Tax
Japan requires Consumption Tax handling and reporting to the tax authorities. The overall process and logics of consumption tax setup and processing is rather familiar to international practice and largely supported in Dynamics AX. Although the consumption tax reports require a lot of configuration, it is provided now out of the box and can be printed through standard functionality. In particular, the Consumption Tax Declaration and Consumption Tax Calculation Sheet are supported.

Japanese Era
Like some other East Asian regions, Japan has its own counting system of years. This counting is based on the name of reigning emperor. The display of year consists of the year (era) name and number of year. This can be followed by month and date. In Dynamics AX, the functionality is addressed by implementing a special date conversion function for Japanese era.

Workflow
Many organizations in Japan might already have workflow system implemented. Therefore, one of the challenging customer requirements would be to integrate their existing workflow solution with Dynamics AX. Such work would require additional customization since no workflow integration solution for Dynamics exists in the Japanese market for the time being. If Dynamics AX workflow system is considered – Japanese organization might ask to have seal (hanko) graphics on the workflow related documents as well as some specific approval workflows like “Googisei”.

Lean Manufacturing
Lean manufacturing originally can be referred to as philosophy derived from Toyota Production System in Japan. “Lean” means a production or business practice that considers the consumption of resources for any other goal than the creation of value to the end customer to be wasteful and to be avoided. Lean is of interest to Japanese as well as many overseas companies. Therefore, Microsoft has implemented rich lean management functionality like Kanban management etc in the global release of Dynamics AX 2012 manufacturing.
Seiban
Seiban is another manufacturing and management practice in Japan likely to require customizing in Dynamics. “Seiban” can be translated from Japanese as “Manufacturing Number”. Seiban number is assigned to parts, materials, purchase orders or other objects for a particular job or project requested by customer etc.

Double-Byte Characters
Languages such as Japanese, Chinese and Koreas require double byte encoding due the vast number of characters in these languages. Double-byte is supported in Unicode. If organization has a non-Unicode system to interface with, then conversion package like HULFT is required.

Some Points Around Management

Change Management: Avoid Rebuilding Legacy Systems in Dynamics
Japan is no exception - enterprise ERP implementations require strong leadership and substantial team efforts across whole organization along with deep business and technology understanding. When faced with these challenges and various dependencies, key users and management might end up basing their requirements on what the old legacy systems delivered. In most cases, this will not take advantage of opportunity to simplify business processes and systems while preventing Dynamics implementation to be on time and budget with expected returns. Successful implementation will need a complete buy-in by the highest members of the IT and business hierarchy to ensure the project is not jeopardized from the start.In reality, not every executive really likes to take responsibility of challenging tasks. The result is having irresponsible members doing irresponsible projects. Therefore, responsibility must clearly be defined in the Project Charter and related documents to ensure commitment by the organization. Sign-off process, timing and signatories have to be agreed before execution of any phase of the project.


Lost in Translation
Notable differences between Japanese and English languages in writing, grammar and cultural contexts mean that it takes much longer for Japanese national to acquire business English skills than people in many other countries. Depending on your implementation project and company, chances are that many key users and managers will not be able to discuss or write freely in English. While cultural context and practices are not scope of this article, Japanese unique cultural context also cannot be ignored.Partial solution is hiring interpreters and translators or using machine translations. While hiring interpreter would make things easier, it can add to project costs and not necessarily avoid miscommunication in the context of particular industry, company and culture. The same consideration goes for machine translation software. While it is very appealing to have whole project documentation translated in just few minutes, these documents can considerably confuse any team relying on translated information. Consider having bilingual team members in the key project roles. These individuals shall sense local context, understand particular business, technology, organization and are to enable smooth knowledge transfer among team members in various language skill levels.


Focus on Detail
Another experience often pointed out by many doing business or implementations in Japan is high attention to detail. Japan is famous for high quality services and products with attention to every detail. As a result, this approach can take much longer time to achieve project objectives due to longer decision making associated with detail preparations and reviews etc. Furthermore, the Japanese management also would like to see the “complete picture”. The combination of these makes developing innovative and leading edge application very challenging. In the past, Japanese did well through reverse engineering and strict discipline, but is struggling with innovations now.

In Conclusion
In general, the ERP requirements in Japan are not so complicated as one could imagine at first. Language and local context can make a significant impact on a project. In the words of long time SAP and Dynamics implementer in Japan, who asked not to be named: “For the project to be a success all the politicians should be aligned from the start and given responsibility and held to those responsibilities – 60% politics, 20% change management and 20% technology is the usual blend of a project here”. The opinions expressed here do not necessary represent the ones of author’s employer.

Introduction to Omni-channel Retailing and Single Platform Approach: Case of Microsoft Dynamics AX 2012 for Retail

Follow @ArtieBe
This article introduces the basic ideas behind Omni-channel concept, explains advantages of adopting a single platform approach as business solution and reviews key retail capabilities of Microsoft Dynamics AX 2012 R3.

Requirement for Omni-channel Approach and System Readiness
Retail is one of the industries experiencing impactful changes. It has expanded from traditional brick-and-mortar to call centers, e-commerce and continuing to shift into social and mobile spaces. One of the new industry buzzwords is Omni-channel retailing (where the word “Omni” stands for “All”). It is retail marketing discipline focused on seamless approach to the customer experience through all available shopping and interaction channels - physical stores, kiosks, call-centers, Web sites, social networks, mobile and even TV and radio can be considered here. This approach means tracking and managing customers, their transactions and experiences across all channels. Unless Omni-channel is successfully adopted, it is not a surprise if a customer is better educated of the latest company offerings than sales staff in a store by learning from their e-commerce site . Furthermore, customer can expect to buy online but pick-up at a store. It means that all retail teams shall have the same understanding, readiness and information from systems available in their roles. Customer will expect to have the same great brand experience in both - the physical world of stores and online. Merchandise and campaigns are expected to bring the same value and experience in all touch points with the customer and not differ by a channel.
As the business technology advances, retailers often end-up with separate systems and multiple vendors for their Line of Business (LOB) solutions to be coordinated and integrated. For example, in-store POS systems, separate solution for call-center, and another platform for e-commerce, native mobile apps etc. These front-end solutions also have to link with back-office (financials, SCM, warehouse etc.) to provide seamless customer experience. Supply chain visibility becomes even more relevant in Omni-channel model since merchandise is now a customer centric as opposed to channel oriented. In not so distant future, a retailer might even like to improve customer service whereby warehouse staff is notified as soon as customer enters a store and triggers communication with a nearby beacon device. More about beacons here.

Approach based on Many LOB Systems
Depending on business strategy and existing IT landscape, a retailer could choose updating and extending their often distinct existing systems and adding new LOB packages to keep up with the latest Omni-channel and industry requirements. At first glance, this sort of gradual approach could seem less risky compared to large overall platform changes like implementing Enterprise Resource Planning (ERP) system with integrated retail functionality. The “Big bang” approach is often avoided due to challenges and dependencies associated with large implementation projects. Meanwhile, the downside of having many LOB packages is enabling integration and middleware among all front-end technologies and their linkage to the back-office requiring investments into analysis, interface development, handling data-integrity as more packages are added, modified, extended or upgraded.

Single Platform Approach
Alternatively to handling many LOB packages, a retailer can consider adopting a single, end-to-end business platform, which can support majority of requirements, require minimal integration, provides extensibility and offers a road map into the future. Integrated ERP for retail approach shall provide one solution for back-office areas such as SCM, finance and warehousing as well as enable centralized data management. Retailer shall be able to manage merchandising, catalogs, run POS and various sales channels including e-commerce, call-centers and have variety of CRM functions. Modern ERP solution for retail should enable Omni-channel capabilities possible for business and united technological platform that IT can support.

Microsoft Dynamics AX 2012 R3 ERP in Retail
Besides the back-office support (finance, SCM, warehousing etc.), Dynamic AX currently offers the following architectural components and functionality in retail as part of one ERP package while not being limited only to these features.

Retail HQ
Retail HQ module allows to configure and administer retail channels as brick & mortar stores, call centers and online stores. Retailer can manage assortments and product selections offered at the stores based on various criteria like region, demographics etc. Retail workers can be assigned roles and privileges. The module allows to manage kits, catalog of products attached to channels with expiry dates control if necessary, pricing, discount, and promotion functionality. Replenishment requirements are also supported with push, cross-docking and replenishment rules. Loyalty program management is available as well as gift card management.
Inquiries functionality provides data on retail transactions, sales, posted statements etc. Periodic tasks include data updates and technical level communication with retail channels.

Retail POS (traditional and modern)
Dynamic AX for Retail provides Point of Sales (POS) program built on .Net framework. POS administrator can customize look and feel - font color graphics of the user interface.
POS application can be role tailored. Store manager can access store reports and real-time sales data. POS solution allows to processes sales orders and codes and cash draw. It provides bar codes, printing of receipts, amount and tax calculations, shift close, gift cards, loyalty transactions and other functions. From back-office perspective, it proves inventory receipting, reporting and stock count.
Along with traditional POS, new in Dynamics AX 2012 R3 is Modern POS app for PCs, tablets and smartphones which allows to process sales transactions, orders and daily operations including some inventory management within the store. It can also be used in conversations with customer - clienteling using product catalog details and Bing maps integration for store locations etc. Modern POS must connect to Microsoft Dynamics AX Retail server which performs business logic and processing.

E-Commerce and Social Features
Online store is one of the retail channels published on SharePoint site from Dynamics AX. Categories and hierarchies are driven out of Dynamic AX and mapped to other channels to enable consistency. Functionality includes shopping card capability, real-time inventory updates, sharing on social networks directly from Web site, pick-up at the store, map integration with Bing to find store and many other solutions.

Commerce Data Exchange (CDX) 
Channel database (or store database) holds data that is required for retail transactions while master data is sent to channels from Dynamics AX database. CDX is a synchronization service that transmits data among head office, stores and channels. Data distribution is asynchronous while in some scenarios require real time communication between Dynamics AX and the channel which is also supported in CDM architecture.

Commerce Run Time (CRT) 
The Microsoft Dynamics AX CRT enables multi-channel commerce capability and provides retail content and services in a scalable way. CRT addresses the requirement to manage different channels with same tool via same logic and integration. It can also serve to innovate with new capabilities on the same platform.

Enterprise Portal for Retail
The Web portal and can be set up for access over the Internet to serve retail team for sales reporting, inventory monitoring, receiving and picking. Retail employees can also view retail products and related detailed information as well as access read-only price adjustments and discounts. Various sales reports, such as sales by hour, worker, store, performance by product, sales or retail category are available. Furthermore, staff can perform stock account over the Internet, receive purchase or transfer orders and complete outgoing transfer orders

Retail Hardware Station
Retail Hardware Station is another novelty in Dynamics AX 2012 R3 providing services for Modern POS clients, peripherals as printers, payment devices to communicate with Dynamics AX.

Introduction to Loyalty Programs or What’s New in Microsoft Dynamics AX 2012 R3 for Retail?

Follow on Twitter

Customer loyalty is often considered as an extensive discipline within CRM (Customer Relationship Management) aimed at keeping existing customers and increasing their satisfaction and revenues to the business. In this article, we will look at what specific mainstream activities are covered under the concept of loyalty program based on the latest R3 release of Microsoft Dynamics AX 2012 Enterprise Resource Planning (ERP) system for retail. This will help to better understand the specific scope of loyalty program management in enterprise, introduce the latest ERP standard solution in loyalty and address key requirements of a typical loyalty program manager.

What is a Loyalty Program?

Loyalty program stands for structured marketing efforts that reward and encourage loyal buying behaviour and results in benefits to the company pursuing such program. Loyalty programs are often associated with physical loyalty cards under various names like point card, membership card, mileage card etc. By presenting such a card at the outlet, customer can qualify for various benefits like discounts, points, and status benefits. Recent new trend is to develop on-line and mobile loyalty programs which require minimal use or even elimination for a need to carry physical card.

Microsoft Dynamics AX package can enable initiatives from simple to complex loyalty programs involving tiers, across multiple legal entities and retail channels (such as, brick & mortar, online, call center). Loyalty managers shall be able to create loyalty schemes and customers to accumulate loyalty points. They also shall be able to enable multiple tier qualification criteria over flexible periods for loyalty status achievement by customers. Multiple programs can be associated to a loyalty card in Dynamics AX and different rewards enabled based on shopper status via tiered loyalty programs. Channel specific loyalty program is an option as well.

Loyalty Points

Loyalty points in Dynamics AX can be based on quantity (such as number of transactions) or amount - sales to customer in set currency. Points in loyalty program can be redeemable in new purchases or in some cases accounted for status change in the loyalty levels (e.g., bronze, silver gold or similar).

Furthermore, redeeming sequence can be controlled in case points are used along with other loyalty rewards in a program.

As many airline passengers already have noticed with their airline miles, points in a program are usually set to expire. In Dynamics AX, expiration time control can be set in days,  months or years.

When it comes to basic reporting, loyalty program administrators or operators shall be able to access summary on points. This includes summary of available points as of today, already issued points, consumed and expired points.

Loyalty Schemes

Loyalty schemes in Dynamics AX specify the rules with details of how points will be administrated and calculated. It serves as connection point between loyalty program and retail channels. It will also determine how customer can earn new points taking into consideration tiers (membership levels) if applicable. Points and status can be earned by activities. Types of these activities as classified by loyalty program are:

1)    Purchasing product by amount

2)    Purchasing product by quantity

3)    Sales transaction count

Furthermore, loyalty manager can choose to set up loyalty schemes by retail product category or limit to particular product for points earning. Loyalty manager is to set how many points are to be earned and when for each rule and for which reward points and to which stores.

Loyalty Cards

Loyal (and also not so loyal) customers can be associated to one or even multiple loyalty cards at the same retailer. Loyalty card can also be applicable to multiple accounts within an organization or family members.

Dynamics AX support loyalty cards for so called omni-channel business scenarios where loyalty program can be executed over various means of communication and sales channels. For example, client can earn points not only when making purchases in a store but also on Web store etc.

More advanced requirement of some interest for couple of companies is support for card tender process – the system can let you to administer if card can be used to earn, only redeem points or both. Example of redemption card could be Disney Rewards Redemption Card which is combined with Visa credit card and allows customer to use Disney Dream Reward Dollars as payment.

Card can be linked to respective loyalty programs and quick summary of points can be obtained.

Controlling of Loyalty Point Transactions

Administering loyalty point transactions could be a challenging area in loyalty program in a large enterprise. The high level requirements include.

 Earning points

Business solution shall be able to control point earning against criteria of loyalty programs. Points shall not be given away if the criteria is not met. To earn points, it is also necessary for the loyalty card to be associated with the point of sale transaction. If the customer is associated to loyalty card then this customer would be added to the transaction.

Redeeming Points
Business solutions shall be able to control that redemption happens only when customer has enough points and is qualified by the loyalty program.

Adjusting points

Sales and customer service issues and exceptions are not seldom happenings. Most of loyalty program managers will likely require ability to directly add points for customer satisfaction or in case of transaction related matters. In Microsoft Dynamics AX 2012 R3, adjustments can be done directly on the card form.

Configuring Dynamics AX 2012 Application

Now that we know loyalty program basics, someone also has to set it up in a business system. On Microsoft Dynamics AX 2012 R3 application side, to create and administer loyalty program, the following are key prerequisite setups.

*  Loyalty date intervals (necessary if tiered loyalty is required)

*  Channels – to link channel to loyalty schemes

*  Retail price groups – to enable loyalty specific pricing

*  Loyalty parameters – default parameter settings

Key setup areas for loyalty functionality itself are:

* Loyalty programs and tiers

* Loyalty points

* Loyalty schemes

* Loyalty cards
Further to basic application side configuration there will be more technical considerations and setups such as smart-card readers, POS support, integration to customer facing membership Web sites etc. We are not covering these scenarios in this article.

Approach as Framework

Real life loyalty program requirements and Dynamics AX capabilities are not limited to the ones described here. Dynamics AX for Retail is to be thought of as a platform. Microsoft Dynamics AX development tools allow extending your loyalty program business solution with new functionality. Furthermore, as retailers try to differentiate their programs from competition - segmentation, profiling, mobile loyalty and many other industry buzz-words and capabilities will have to be supported in near future. Having integrated ERP package as backbone enabling basic framework of loyalty program administration and other retail functionality could an approach to take at retail organizations.

Using Hyper-V in Windows 8 to Run the Latest Dynamics Products for Enterprise

One of the main reasons to use Windows 8 in my role is Hyper-V Manager available now within the new OS. This allows me to run Dynamics AX 2012 or Dynamics CRM 2011 from my PC by using virtual machines with Windows Server, Microsoft SQL, SharePoint and other required enterprise systems installed. Hereby, we can use Windows 8 for demo, training, and testing of the latest Dynamics products for enterprise by using just one PC.