mopdf.com

Architecture and Application Architecture and the alignment between Information Architecture and ApplicationArchitecture. We also used other set of metrics, the metrics list from (André Vasconcelos P. S., 2008). From thatlist we chosen the following three metrics: the Average Number of Operations in «IS Blocks», the Response for aService Factor and the Lack of Cohesion in «IS Block» Factor.2.2. Customer Relationship ManagementKenneth C. Laudon and Jane P. Laudon defined CRM systems as a way to: "capture and integrate customer datafrom all over the organization, consolidate the data, analyze the data, and then distribute the results to varioussystems and customer touch points across the enterprise." (Laudon, 2012)The CRM software companies provide solutions for three major areas: sales force automation, marketingautomation and customer service. The CRMs have also three major technologies: collaborative technologies,operational technologies and analytical technologies. (Laudon, 2012)2.2.1.Customer Relationship Management FeaturesTo specify the functionalities of our CRM Reference Architecture, we extracted the features of five known CRMsolutions and made a comparison on what features were common between them. The five CRM solutions are:SugarCRM, Microsoft Dynamics, Sage CRM, Oracle Siebel and Salesforce. The common features between themwere the features chosen to be the functions of our Reference Application Architecture. We grouped the featuresin seven groups, in accordance with the CRM solutions datasheets. The extracted features are: Sales features: account management, activity management, approvals, competitor tracking, contactmanagement, contract management, sales literature, lead management, opportunity management, productmanagement, quote management, sales forecasting, territory management, order management, quotamanagement and sales pipeline; Marketing features: campaign management and execution, email marketing, newsletter management,marketing campaigns, list management, lead management and web to lead capture; Customer Service features: case escalation and notification, case routing and queuing, case management,contact center, customer self-service portal, email management, knowledge base, customer information andservice contracts; Reporting features: custom reports, dashboards, sales analytics, marketing analytics and service analytics; Integration features: email integration, social networks, integrated third-party apps, web services API –SOAP, web services API – REST, computer telephone integration, automatic call distributor, Microsoft officeintegration and cloud connectors; Security features: role based security, advanced password management, audit trail, field level security, userbased security and team based security; Other important features: workflow processes automation, document management, offline and online access,data deduplication and calendar management; (Oracle, 2007) (Salesforce, 2012) (Sage, 2012) (SugarCRM,2014) (Microsoft, 2008) (Oracle2, 2007) (Oracle3, 2007) (Microsoft2, 2008) (Microsoft3, 2008) (Oracle4,2007) (Oracle5, 2011) (Hariharan, 2009) (Microsoft4, 2008)2.2.2.Customer Relationship Management Information EntitiesAfter the identified features, we extract the common information entities from the data models of the five CRMsolutions chosen. For the identification, we did a mapping between the identified information entities of eachCRM solution, to reach the common information entities. In this mapping of information entities we also usedthe (Buttle, 2009) reference for the identification of the information entities and their relations.The common information entities identified are: customer, account, organization, person, partner, contact, salesactivity, competitor, competitor product, contract, lead, prospect, opportunity, quote, forecast, quota, territory,customer product, order, invoice, product, price, product catalogue, campaign activity, campaign, campaignwave marketing funds, marketing segment, marketing budget, marketing plan, campaign response, marketinglist, service activity, case, case solution, email, call, communication, portal, user, group, sales team, service team,scheduler, calendar, report, dashboard, workflow, document, knowledge article, person address, order item, userrole, user login, user contact. 1 2 3 4 In some cases of these information entities, in order to simplify, we cluster /docs/api/Content/data E6.0GA/SugarCE6.0.4/Sugar6.0.0 CE Schema hbgpyd91/New Sage CRM Data ModelSummary of dissertation for Master degree, Instituto Superior Técnico, Lisboa, May 20153

divide some them: the campaign activity aggregates the campaign activity and campaign wave; opportunityaggregates opportunity and opportunity item; order aggregates order and order item; person aggregates personand person address; user aggregates user, user role, user login and user contact; contract is divided in twospecialized information entities the sales contract and the service contract.3. ARCHITECTURE SOLUTIONIn this section we present the Reference Architecture solution proposed. To reach this CRM ReferenceArchitecture we use a methodology. The methodology has three steps. In the first step we define the mission,vision and strategy of the Reference Architecture, which are: Mission: provide guidance, knowledge, architectural blueprints and improvement in CRM domain; Vision: be the most complete Reference Application Architecture in CRM domain; Strategy: extract best practices regarding CRM domain, define the Reference Architecture based on thosebest practices and evaluate the Reference Architecture in case studies, in order to improve it;The second step of the methodology corresponds to the representation of the common features identified insection 2.2.1 in application architecture, becoming the first view of our Reference Architecture (Cruz, 2015). Thereached Reference Architecture is composed by ten identified CRM modules, which are: Sales module,Marketing module, Service module, Calendar module, Reporting module, Security module, Mobile module,Document Management module, Integration module and Workflow module. Each of the modules has a set offeatures chosen from the features identified in section 2.2.1. The features common to at least three of the CRMsolutions, were the ones chosen to be part of the Reference Architecture.The third step is where we reach a complete Reference Architecture. To reach the Reference Architecture we usethe previous identified functionalities, with exception to the Integration features, because we considered that theIntegration features are more regarding the Technological domain than the Application domain. Thosefunctionalities are going to be mapped in a CRUD matrix with the common information entities, identified insection 2.2.2. Those information entities allowed also the definition of a Reference Information Architecture.With the CRUD matrix we reach a Reference Application Architecture, illustrated in Figure 1.Figure 1 - Reference Application iebel-data-model-reference-82Summary of dissertation for Master degree, Instituto Superior Técnico, Lisboa, May 20154

The reached Reference Application Architecture is composed by six modules: account module, sales module,marketing module, service module, scheduler module and administration module. The Reference Architecture iscomposed also by five systems, which interact with the CRM system: portal system, contact center, documentand knowledge base management, reporting and analytics system and workflow management system.Each module and system has a set of functionalities which are: Account module: contains account management, contact management and customer information functions; Sales module: contains activity management, sales pipeline management, competitor tracking, contractsmanagement, lead management, web to lead capture, opportunity management, quote management, salesforecasting, quota management, territory management, order management and product and catalogmanagement functions; Marketing module: contains campaign management, campaign execution, email marketing, marketingcampaigns, newsletter management and marketing list management functions; Service module: contains service contracts, case escalation and notification, case routing and queuing, casemanagement, email management functions; Administration module: contains user authentication, team authentication, role authentication and fieldpermissions functions; Scheduler module: contains calendar management function; Portal system: contains customer self-service portal, mobile and offline access functions; Contact Center system: contains contact center function; Document and Knowledge Management system: contains sales literature, document management andknowledge management functions; Workflow Management system: contains workflow processes automation management function; Reporting and Analytics system: contains dashboards, reports, sales analytics, service analytics andmarketing analytics functions;The final part of the work regarding the proposed Reference Architecture solution is the identification of theEnterprise Architecture Principles that are satisfied by it. We identified eleven principles that are satisfied in theReference Architecture, which are: customers have a single point of contact, processes are standardized, frontoffice processes are separated from back-office processes, the status of customer requests is readily availableinside and outside the organization, documents are stored in the document management system, reporting andanalytical applications do not use the operational environment, applications are modular, applicationfunctionality is available through an enterprise portal, processes are supported by a business processmanagement system, authorizations are role-based, access to it systems is authenticated and authorized.(Greefhorst, 2011)4. EVALUATIONIn this section we present the evaluation done in the case studies. We start by explaining the methodologyfollowed for evaluating each case. The methodology consists in two steps: Step 1: we analyze and extract from the provided documents of each case, the business processes, theinformation entities, the CRM modules and the systems that interact with the CRM system. From thisinformation we reach an Application Architecture for the current state of the case study. Then with the sameinformation extracted from the documents, we verify how our Reference Architecture satisfies them and wereach a specific architecture for the case study based on our Reference Architecture. Step 2: we apply the chosen metrics and heuristics for information systems evaluation, present in section2.1.5, in the architecture of the current state of the case study and in the architecture reached from ourReference Architecture. In the end we take conclusions on the results obtained.In this article we only present one of the case studies evaluated.4.1. Case StudyIn this section we present one of the case studies where we evaluate our Reference Architecture. All the caseswere provided by the Agency for Administrative Modernization (AMA). It is important to refer that the caseswhich we evaluate are all in the public sector domain, despite our Reference Architecture being based on CRMsolutions for mid-market companies. If in the case studies are identified some patterns that aren’t covered by theReference Architecture, those patterns may be added to the Reference Architecture in the end of the evaluation,in order to the Reference Architecture in terms of the public sector domain.Summary of dissertation for Master degree, Instituto Superior Técnico, Lisboa, May 20155

4.1.1.High Commissioner for the Migration (ACM)The ACM is a public institute with the goal of cooperating in the definition, execution and evaluation of publicpolitics, transverse and sectorial policies on migration, relevant to the attraction of migrants in national andinternational contexts. The ACM is also responsible for the integration of immigrants and ethnic groups, inparticular Roma communities, and for managing and valuing diversity among cultures, ethnicities and religions.We experienced the CRM from ACM (Ruivo, 2012), and from that we extracted the following businessprocesses regarding CRM domain: Customer Management Processes: create customer form, associate customer, edit customer, list customers; Processes Management Processes: create process, edit process, list processes, close process, write a note; Tasks Management Processes: create task, edit task, list tasks, write a note; Follow-Up Management Processes: edit follow-up, list follow-ups, do a follow-up on a process; Service Management Processes: begin service, close service, resume service, list services; Scheduler Management Processes: create schedule, edit schedule, assign ticket, list schedules, call customer; Document Management Processes: upload document, disassociate document, edit document, list documents,visualize procedural document, visualize personal document; Report Management Processes: generate offices call report, generate service users report, generate reportoffice processes, generate report processes users; User Management Processes: user sign up, user login, user profile, password recovery, visualizenotifications; Administration Management Processes: list users, create new user, user profile, edit user, list teams, createteam, team profile, edit team, list profiles, create new profile, profile of profile, edit profile, list modules,module profile, edit module;After the identification of the business processes, we identify the information entities used in this CRM, whichare: note, process, task, request, scheduler, ticket, document, follow-up, customer, user, report, permission,profile and team.We also identified the main modules of this CRM and the interacting systems, and with all these information wecan represent the CRUD matrix, and through it reach the Application Architecture, illustrated in Figure 2.Figure 2 - ACM Application ArchitectureSummary of dissertation for Master degree, Instituto Superior Técnico, Lisboa, May 20156

In the Application Architecture of the ACM CRM, we identified eight modules and four systems whichinteracted with the CRM: Processes Module: provides processes management functionalities; Follow-Up Module: provides follow-up management functionalities; Task Module: provides tasks management functionalities; Client Module: provides client account management functionalities; Customer Service Module: provides customer service management functionalities; Scheduler Module: provides scheduler management functionalities; User Module: provides users management functionalities; Administration Module: provides administration management functionalities; Document Management System: provides document management functionalities; Reporting System: provides reporting management functionalities; SIGA System: provides ticket management functionalities; Portal System: front-end platform that communicates with CRM API’s and provides an easier interface. Thissystem wasn't identified in the CRUD matrix, instead it was identified through the contact with AMAresponsible;We arrived at the Application Architecture of the ACM CRM, so is time to reach a specific architecture based onour Reference Architecture. We reach an Application Architecture with the Reference Architecture guidance,illustrated in Figure 3. The changes made because of the best practices are: We grouped the Request, Follow Up, Process and Task modules into one module, the Service module,because the Service module in our architecture has the case management functions, which includes thefunctions of these four module; The User and Administration modules correspond to a single module in our architecture, theUser/Administration module; The Client module in our architecture goes by the name of Account module; The system that wasn't covered by our Reference Architecture stayed the same. In this case is the SIGAsystem;Figure 3 - ACM Application Architecture from Reference ArchitectureSummary of dissertation for Master degree, Instituto Superior Técnico, Lisboa, May 20157

In the Application Architecture for the ACM CRM case based on our Reference Architecture, we identify fourmodules of the CRM System and four systems that interact with CRM System: Account Module: provides client account management functionalities; Service Module: provides customer service management, processes management, follow-up management andthe tasks management functionalities; Scheduler Module: provides scheduler management functionalities; Reporting and Analytics System: provides reporting functionalities; User/Administration Module: provides administration and user management functionalities; Document and Knowledge Management System: provides document management functionalities; SIGA System: stays the same; Portal System: stays the same;The final step is to evaluate both Application architectures with the metrics and heuristics to evaluateinformation systems chosen in section 2.1.5. The results obtained are present in the Table 1.Table 1 - Evaluation ResultsEvaluated Qualities CriteriaACM Current StateArchitectureACM Architecture by Ref.ArchitectureChange Facility (Application)0,3050,194Test Facility0,2070,235Change Facility (Information/Application)0,99350,9897Alignment between BusinessArchitecture and InformationArchitecture0,666 (66,6%)0,666 (66,6%)Alignment between BusinessArchitecture and InformationSystems Architecture1 (100%)1 (100%)0,714 (71,4%)0,857 (85,7%)Alignment between InformationArchitecture and InformationSystems ArchitectureFrom the Table 1, that presents the results of the evaluation done on ACM case, we can conclude that thesolution from the Reference Architecture has a better alignment between Information Architecture andInformation Systems Architecture and a better test facility, but it has worst change facility. The test facility resultis better because the solution from Reference Architecture uses less CRM modules. The change facility is worsebecause of that same factor, the current state of ACM architecture has more CRM modules, so is easier to changethan an architecture with less modules. Regarding the better alignment between Information Architecture andInformation Systems Architecture, this happens because in the ACM current architecture there are variousmodules that manage the same entities, and in the solution from the Reference Architecture this doesn't happen.ObservationIn this subsection we identified the limitations of our solution in this case. In this case study two informationentities weren’t covered by our Reference Architecture, the note and ticket information entities. The process andfollow up entities correspond to the case information entity in our Reference Architecture. In relation to theinteracting systems our Reference Architecture also didn't took into account the SIGA system for ticketmanagement. Regarding ticket management our Reference Architecture only took in account that the CRMmanage the cases and route those same cases.4.2. Case Studies PatternAfter the evaluation done, we identified a pattern from Portuguese Public Administration regarding CRM presentin both cases evaluated that wasn't covered by our Reference Architecture. The pattern is regarding the SIGAsystem, a system responsible for ticket management, which appears in both case studies interacting with CRM.Summary of dissertation for Master degree, Instituto Superior Técnico, Lisboa, May 20158

The interaction between that system and the CRM, involves in the two case studies two different CRM modules.In the first case study (the case demonstrated in this article) the SIGA system interacts with the Schedulermodule and in the second case study interacts with the Service module. From this observation we can represent apattern regarding the CRM domain in Portuguese Public Administration that wasn't satisfied by our ReferenceArchitecture and that can be added to it for improvement in this sector. The pattern is illustrated in Figure 4, andwe named it the SIGA pattern.Figure 4 - SIGA pattern5. CONCLUSIONIn this section is where the main conclusions of the work done are taken. Where are explained the achievementsreached with this work, the principal contributions, the limitations of the solution and thoughts regarding whatcan be done for future work.5.1. Major ContributionsThe whole work done in this thesis was in order to provide a Reference Architecture for the CRM domain.Therefore the main contribution is the proposal of a Reference Application Architecture for the CRM domain.This Reference Architecture was defined based on the analysis done on five CRM commercial solutions.Through that analysis, we identified six CRM modules and five systems that interact with the CRM system. Thesix CRM modules are: Account module, Sales module, Marketing module, Service module, Administrationmodule and Scheduler module. The five systems that interact with the CRM are: Portal, Contact Center,Document and Knowledge Base Management system, Workflow Management system and Reporting andAnalysis system. In order

Customer Relationship Management Features To specify the functionalities of our CRM Reference Architecture, we extracted the features of five known CRM solutions and made a comparison on what features were common between them. The five CRM solutions are: SugarCRM, Microsoft Dynamics, Sage CRM