SAP

Quality in Software Projects

Implementation projects for IT systems are often subject to extreme time and budget constraints. Even if the initial project planning is realistic, pressure can arise from the following factors :

ü  Late or drawn out project start;

ü  Use of capacity elsewhere (especially if the workload for ongoing everyday tasks has been underestimated);

ü  Changes in the  project team members during the project execution;

ü  Constantly changing requirements during the project execution stage.

When projects are under pressure to meet a deadline or stay within a specific budget, quality is often neglected to save resources . This is a short term approach, however, it may help to keep deadlines when running  projects with short runtimes, but at a price for a much poorer quality .

Typical Quality problems can be divided into four main categories:

ü  Incorrect Definition of requirements

The first project phase  is used to generate system requirements. Due to communication problems or the inclusion  of the wrong group of people, the planned processes are often misunderstood . Just as frequently, individual processes or process variants are completely overlooked. In both cases, these mistakes may only come to light during the end user training

Or even during the production support operations stage.

 

ü  Incorrect Mapping of Requirements

This is the classic "quality problem" that often the users define as  a "program error" leading to incorrect system behavior. Along with a clear concept and a well-defined project team, structured tests are indispensable .

 

ü  Incorrect use of System

System providers and consultants (even the internal business users) are often all too eager  to call these problems "user errors" thereby removing them from their area of responsibility - even though the users are not completely without responsibility in the situation. Change management in its broadest sense (including user specific training) and optimal system support (ex: via plausibility checks) can, however reduce the user errors during the implementation

 

ü  The Maintenance Trap

Quality problems that occur only some time post the production support starts can also be tracked back to implementation. Missing documentation  or badly structured  customizing or program could not that makes the maintenance more the difficult.

 

 

Posted by Shovan Sahu at 11:23 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Architecture for any IT based solution is a most important factor for aligning IT with business expectation. This also facilitates a transparent and manageable roadmap for most adaptable and efficient system landscape. An effective architectural design of a solution helps business to fulfill their target in an open, scalable and easy to handle infrastructure. This blog will focus on approach of an architecture design for SAP Netweaver based solution.

 Before starting an architecture design, first make a decision about the platform on which the solution will be built. As this blog is considering SAP Netweaver based solution as an example, the solution in discussion will be built on SAP Netweaver platform. First step is to consider Basic Architecture of the decided platform for the solution. It means the basic architecture of Netweaver based solution is briefed in a refrigerator-type diagram as shown below:

Once basic architecture is defined, we need to go through the use cases for the solution. Based on the use cases, the decision has to be made on component of Netweaver stack to be used for solution design. For example, use case says develop a User Interface which will be used to display analytical reports based of user's input data. Based on this use case, solution needs at least Portal, Business Intelligence (BI) and J2EE application server. This is the minimum component required to fulfill the use case requirement. So this is the second step for defining architecture for a solution and is called minimum infrastructure based on solution concept.
The third step is to finalizing different components required to implement this solution and is called minimum infrastructure with respect to SAP product. Different phases involved with solution implementation are Blueprint, Build, Execute and lifecycle management. In this step, SAP product has to be outlined for different phases of solution implementation. For example, to build portal based application, we need Netweaver Development Infrastructure to manage coding other than portal application server. Other different products might require are CTS+ for transport, NWA for administration and others.
Once all products decided for solution implementation, the last and final step is detailed solution deployment infrastructure. This step can be achieved by applying different architectural/deployment principles applicable for the selected products and recommended best practices for those products. Based on this step, an architect can revisit the decision made in previous step to give more effective design.

Below content showcases the points discussed above:

1. Base Architecture(Solution IT platform)
2. Minimum Infrastructure (Based on use case concept): Influenced by Solution Use Cases
3. Minimum Infrastructure (Based on SAP product)
4. Detailed Solution Deployment Infrastructure: Influenced by Architectural Principles, Deployment Principles and Best Practices.

Posted by Ranjeet Kumar Jha at 5:07 AM | Permalink | Comments ( 0 )

In the first part of this blog, we discussed key elements of Mobile BI, options for delivering BI content on mobile devices and business scenarios best suited for mobile usage. Now let's talk about specifics from SAP in this area. I will cover various technology options from SAP, their use cases, device support and some future enhancements from SAP.

Mobile BI is not new at SAP. Business Warehouse 3.0 offered what was known as BEx Mobile Intelligence. It facilitated rendering BEx Web Reports, developed using Web Application Designer (WAD), on PDA's and WAP-enabled phones. It had device recognition and rendering capability which meant that you could create one single template and use it on multiple devices.

The product was meant for early generation PDA's and WAP phones, and did not really come up to newer feature-rich and highly capable "Smart Phones". BEx Mobile Intelligence has not seen any new upgrades or enhancements in a long time. One of the reasons could be SAP's acquisition of BusinessObjects (BO) and its strategic decision to make BO as the primary Business Intelligence offering. If you are looking to start your Mobile Business Intelligence now, you should not consider BEx Mobile Intelligence as a strategic tool (it could be used a quick-win tactical solution though).

So what are the Mobility options on BusinessObjects toolset? At a high-level there are two; BO Mobile and BO Explorer Mobile. Both these serve different purposes. BO Mobile is meant to deliver targeted BI content to users based on their roles, whereas BO Explorer Mobile allows users to use search and exploration feature of Business Explorer via mobile devices. In other words, BO Mobile allows users to access predefined purpose-built BI applications from their mobile devices and BO Explorer provides them Google-like search feature to analyze data using auto-generated data visualizations on mobile.

BO Mobile enables accessing Web Intelligence (WebI) and Crystal reports content on Mobile through a device-specific client application (or "app"). It allows users to connect to BusinessObjects servers in the corporate network through mobile and render the reports that are already published on the server for that user/role. Although the reports have to be predefined, neither the data is not static nor are the reports "broadcast" to users. BO Mobile allows users to access the content on-demand (or "pull") and interact with it. Some of the key features it provides are document refresh, changing filter values (prompts), drill-downs, navigation to other hyperlinks defined on the report, invoking device-specific actions such as phone call, SMS text or Email, and sending document link via email, etc. It also allows users to receive alerts when a document is refreshed on the server or an exception condition is met. Users can also download report on the local device and access offline.

BO Mobile is supported on Windows Mobile, Nokia and BlackBerry Smart Phones. In June this year, SAP also released an app that allows accessing WebI reports on iPad. For iPad support though, you need BO 4.0 SP2 or BO XI 3.1 SP4 on the server side. Also, currently iPad only renders WebI reports (no Crystal) and some features like drilldown are not supported. But I must say that the visualizations on iPad look gorgeous!

Now let's talk about BO Explorer Mobile. This product extends the core search-and-exploration capability of BO Explorer to mobile devices. As we discussed earlier, the use case is completely different from BO Mobile. Here the objective is not to render pre-defined BI content, but to allow users to perform ad-hoc analysis. Visualizations are automatically generated by the system, similar to BO Explorer on desktop. However some backend work in terms of defining InfoSpaces etc. is still needed. You would need BO Explorer installed and configured on top of your BusinessObjects environment, and for a superior performance an accelerated (in-memory) version is recommended.

Currently the BO Explorer Mobile is available for iPad and iPhone as a downloadable app from Apple AppStore.

Both the above products do not address one key ask of many organizations and users - Xcelsius Dashboards. So how does one access Dashboards on the mobile? Well, there is one option. As most of you would know, Xcelsius Dashboards are rendered using Adobe Flash running in device browsers. So, technically, any device that can run Adobe Flash can render Xcelsius Dashboards. Users using Android devices (Smart Phones or tablets) or BlackBerry PlayBook can simply access Xcelsius Dashboards through their device browsers. As discussed in the first part, this is an example of RIA rendering. Only condition is that your BO Enterprise server should be accessible via Internet/VPN and device should support Flash. However as we all know, within tablet space, iPad is the big elephant, and since iOS devices do not support Adobe Flash, currently iPad and iPhone cannot run Xcelsius Dashboards. L

So as you might agree, SAP provides quite a lot of options and features to mobile enable your Business Intelligence. But I think there are some key elements still missing -

1.    BO Mobile support on iPhone (currently only iPad is supported)

2.    Drilldown functionality on iPad/iPhone

3.    Ability for users to customize charts/reports and save views

4.    BO Mobile and BO Explorer Mobile support for Android devices

5.    Xcelsius on iPad/iPhone

As per SAP, many of them would get addressed in the newer releases that are in "pipeline". (Disclaimer: product directions are subject to change)

Device support - Support for iPhone, Android devices and BlackBerry Playbook

Feature enhancements - Drilldown on iPad/iPhone

Explorer Augmented - Will integrate location awareness, device camera and map visualization in BO Explorer Mobile

Exploration Views - An extension on BO Explorer Mobile allowing users to customize and share different visualizations.

Unified Mobility Platform - An integrated platform for Business Process Mobility and BI Mobility. Currently both exist as independent product stacks (Sybase and BO Mobile) and technologies.

Well, that concludes this 2-part blog. In Part-1, we discussed generic aspects of Mobile BI, and in this part technology options from SAP. Hope you found them useful. Do write-in your comments/views/suggestions...

 

Posted by Parag Shrungarkar at 8:41 PM | Permalink | Comments ( 2 ) | TrackBacks ( 0 )

Continuing from my blog on BI 4.0 strategic direction on the reporting platform http://www.infosysblogs.com/sap/2011/10/arrived_sap_business_intellige.html, I would now like to focus on the strategic direction being taken around data integration or Information Management (IM).

·         Finding your place

When we talk about Information/Data Management we usually talk about 3-4 broad areas:

·         Data Integration

·         Data Quality

·         Metadata management/master data management

SAP is addressing the above through its offerings around Business Objects -Data Services (DS) and Business Objects -Information Steward (IS). While Business Objects -Data Services combines the ETL from its legacy BO- Data Integrator (DI) and Data Quality (DQ) ,which in turn was acquired by Business Objects after its purchase of First Logic in early 2006. This combination of BO-DI and BO-DQ had anyway happened in the version 3.x. However Version 4.0 takes things further in terms of enhancing and automating the data quality checks [Checking the authenticity of postal codes of China] is a case in point and creating a homogeneous offering of the ETL and data cleansing capabilities.

On the other hand the functionality that Information Steward brings to the table is a full suite of data profiling, rules builder as well as metadata management capabilities. Version 4.0 provides a nice integrated interface of all these sub application in an easy to use navigation.

While all these functionalities are needed  for building a best in class data management solution I  as an IT practitioner would prefer to see the data profiling and rules builder to be closely working with my data quality platform.  In a typical data enrichment process I would approach it in the order of Data Profiling à Rules Package Builder à Data Quality/Cleansing. To do that I would rather have all these functionality integrated together on a single platform.

At the same time I can possibly see the direction that SAP is taking with regards to the positioning of BO-DS and BO-IS would be for two different set of people in the enterprise. While BO-DS would remain positioned for the IT department, BO-IS given its highly interactive interface is for the business analyst's use. Here SAP is towing the copybook line whereby it is said that business knows data better than IT and there cannot be two ways of looking at it!

·         The Power of NOW

A lot has been said and debated on the need and ability to deliver analytics on a real time basis. SAP's offering with Events Insight tries to address this space.  It can raise alerts on a 'near' real time basis.  Using Sybase Complex Event Processing (CEP) capabilities it is able to match patterns and recognize occurrences.  The use of this tool, I think can largely lie in the area of Business Activity Monitoring as well. However the added capability that Events Insight provides its ability to integrate with BI analytics engines like dashboards and reports.  I see logistics organizations being able to make good usage of its capabilities.

Posted by Somnath Mukherjee at 11:25 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

by Madhup Mukund Paturkar

In last blog we discussed about why regression testing should be automated. Also we discussed about the contents & important of Process Mapping and Test cases. In this blog we will look at the approach to automation project and tools provided by SAP.

Approach to test automation project:
The approach to SAP automation will also depend on many other non technical issues few examples are business process readiness, test case readiness and budget and time constraints.

 

Above figure shows simple execution model for the automation project. Ideal way to do automation project can be with upgrade or any rollout where regression testing is being done manually. But before you start the automation project, it is expected that Process Maps are ready. Test case preparation and test data creation for the process along with automation can be achieved as a parallel process to any big project or upgrade. This gives saving of effort in terms of test data and test case creation. The same test cases and test data can be used in automation as well it helps to do the regression testing during big project or upgrade. To keep the momentum it is expected that you finish the automation project along with the regression testing of the already running project. Automation will always be lagging functional test data creation.

Operating model shows the tools used and data flow. It is expected that senior functional consultant to create detail business process flows. Based on the analysis of the flows functional consultant can create the test cases as explained in first blog. The variation of test data for a unique t code needs to be captured in test case. Automation team will need details of the flow and test data for the flow as well as test case. Test automation team needs a close co-ordination with functional team to understand the flow and variations. SAP experienced test automation consultant in this particular model is added advantage.

Tools required in test automation:
In order to run the entire project efficiently, you need tools like SAP TAO, HP QC, QTP and Solution Manager. ARIS is a tool provided by Software AG Company which has a very strong integration with Solution Manager. Process can be mapped in Solution Manager or ARIS-Solution Manager together. ARIS gives a very good front end for end users to understand the process and further enhance it. Purely from automation point of view ARIS is not mandatory.

Solution Manager has direct link with QC to create the requirements. Actual automation is done with help of SAP TAO and QTP. SAP TAO helps a lot in generating the components from SAP. Details about these tools are generally available on web.

Posted by Madhup Mukund Paturkar at 3:41 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

With significant new advancements in mobile technology and devices capabilities, coupled with growing importance of Business Intelligence (BI) within organizations, it is no surprise that Mobile BI is gaining so much attention. In the first part of this 2-part blog, I will discuss key elements of Mobile BI, options for delivering BI content on mobile devices and business scenarios best suited for mobile usage. In the next part, I will cover Mobile BI technology from SAP BusinessObjects perspective.

Let's first start by defining what Mobile BI is. In my view, a Mobile BI is an interactive BI application catering to a specific business scenario and tailored for mobile usage and devices.

First and foremost, it is an interactive application that allows users to "play" with it by way of slicing, dicing, filtering, etc. It is not a simple static web page or PDF that is broadcast to users' mobile through emails.

Mobile BI is not just another frontend. Mobile BI application needs to be designed keeping in mind the business scenario that it will be catering to. Not all scenarios are suited for a mobile use, and mobility option should not be "enabled" for all BI applications.

Another side of the above coin is that BI applications need to be tailored for mobile usage. A report designed for desktop or web usage might work as-is on a mobile device. However for optimum usage on a mobile device, a Mobile BI application needs to be tweaked/customized considering various factors such as screen size, amount of data to be passed over the air, device capabilities and features, etc.

Lastly, the device support. Each device type has different features, capabilities and limitations. Typically you would not be able to create a BI application that will work the same way on all devices, unless it is a static HTML or PDF. So you would need to tailor your application for the most commonly used devices by the users of your application.

From a device type perspective, Mobile BI is targeted towards the Smart-phones and Tablets. Although BI on Smart-phones has been around for quite some time, it is the emergence of Tablets that has created whole new opportunities for Mobile BI. Many analysts feel that a tablet is the right device for delivering BI content on mobile given its screen size, processing power and interactive touch capabilities.

Let's discuss the ways in which BI content can be delivered on mobile devices. There are primarily 3 options and each has its pros and cons. But the choice really boils down to how much customizing/maintenance effort you are willing to spend vs. the user experience expected.

1.     Delivering BI Content on Device browsers - This has the least amount of customizing effort and will work similarly on most devices. But on the flip side, user experience is quite basic and does not take into account device capabilities.

2.     Delivering BI Content through Rich Internet Applications (RIA) e.g. Adobe Flash - Here too customizing effort is not significant and it will work similarly on most devices. Also it provides great interactivity as compared to a plain browser. However it does not leverage device features and moreover not all devices support all RIA. For example, Apple iOS does not support Adobe Flash!

3.     Delivering BI Content on device specific applications - This provides the best user experience leveraging device features and capabilities. However, applications need to be customized for each device type leading to higher customizing and maintenance effort.

I earlier mentioned that not all business scenarios are best suited for mobile usage. So where would Mobile BI make most sense?

•       Providing on-demand access to BI for people on the move E.g. Field sales/service staff

•       Mobile BI applications for people without regular access to traditional BI E.g. Shop floor managers, Retail store managers

•       BI applications where data is updated frequently E.g. Inventory, Health & Safety incidents

•       Integrated workflow and BI applications E.g. Approval for temporary credit limit increase for customer based on customer analytics

So we discussed key elements of Mobile BI, options for delivering BI content on mobile devices and business scenarios best suited for mobile usage. In the next part, I will cover Mobile BI technology from SAP BusinessObjects perspective.

Hope you found it useful. Do write-in your comments/views/suggestions...

Posted by Parag Shrungarkar at 7:26 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

by Madhup Mukund Paturkar

Regression testing, Integration Testing and Unit Testing, all form important part of any SAP project. Testing is necessary but never sufficient. Testing becomes more complex in global-local object development scenario with multiple SAP clients across the geographies. In such scenario any rollout or a complex enhancement should ensure that regression testing is sufficient so that it does not affect normal operations.

This entire activity needs effort and costs dollar every time you do it. Question which I would like to address is, can we avoid it? If yes, how to go about it and with which SAP tools? In this two blog series I would like to take you through some of the basic readiness checks in order to start the automation project so that you can achieve maximum efficiency during the project and SAP tools with methodology.

Here I am focusing on automation of regression testing. Never-the-less, automation can be extended to other type of testing as well.

Process mapping:
To do the automation, basic requirement is to have business process documented in the same sequence as it happens in production environment. The scope of process should include all manual activities, automated jobs, interfaces (inbound / outbound) and all legacy system related activities. To limit the scope till regression testing you need to identify and document all processes which you would like to include as part of regression testing or else entire process mapping in itself will be a big project.

Process should have a documentation of SAP T code, program or interface being used. Also it should clearly indentify the SAP fields which are passed from one step to another in order to completely execute the process. This is very important from automation point of view.

Test cases for SAP Component:
Process mapping will give you entire repository of SAP T code, programs and interfaces used as a part of regression testing. The test cases have to be prepared for each of these SAP components in the way they are used in a process. For example ME21n may be used in multiple type of procurement process. The test case should be unique for a t code / program / interface irrespective of multiple usages in processes. So ME21n test case should document as many variations of procurement process. The test case should clearly identify the process / processes in which the component is used.

Content of Test case:
Normally the test cases are prepared from the point of view functional or technical usability. In case of automation the nature of test case will differ a little. The test case should contain following important points:

1)      Steps to execute a particular t code / program / interface

a.       If a t code / program / interface are used in more than one way then test case should include all such possible variation. The possible variation can be concluded from the usage of the object in various processes. Extrapolate the ME21n example.

b.      Success message for each t code / program / interface should be clearly identified with screen shot.

 

2)      Data for the execution of t code / program / interface

a.       If a t code / program / interface need more than one type data then all such data requirements should be documented. The possible variation can be concluded from the usage of the object in various processes. Extrapolate the ME21n example.

b.      The data should be captured in such a way that the same data can be used when the t code / program / interface is used in the process.

c.       If the data is received from the previous step or has to be used in next steps then it has to be identified explicitly.

In next blog we will look at the approach to automation project and tools provided by SAP.

Posted by Madhup Mukund Paturkar at 7:14 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Electric Vehicle adoption is becoming a reality worldwide and it is growing at an accelerated pace. Automobile manufacturers across the globe are focusing on developing electric vehicles for mass consumption. The developed nations specifically are seeing this growth which is fueled by numerous factors like:

• Electric vehicles are becoming more and more affordable. Coupled with innovative buying campaigns, it is driving purchasing

• Lower cost of ownership of electric vehicles since these are not dependent of traditional fuels and simpler mechanical technology translates into lesser maintenance and failures

• Increasing cost of fossil fuels since most nations are dependent on imports for such fuels and hence often consumers are opting for their small vehicle as an electric vehicle

• Environmental concerns caused by use of traditional vehicles with some nations having high taxation on these

• Rebates and concessions offered by governments in use of electric vehicles either directly or indirectly

While all this growth of electric vehicles is good for the economy, good for the environment and of course translates into additional revenue stream for automobile manufacturers, electric utilities are really concerned on how they can address the impact to their business, planning and supply of electricity by this increasing use of electric vehicles.

Charging an Electric Vehicle consumes and demands significant electricity when compared to the overall household consumption and average demand in a billing period. Hence increase in use of electric vehicle creates additional consumption and demand requirements. Some of the challenges that electric utilities are facing with the use of electric vehicles are:

• Utilities are unable to plan additional consumption or demand from use of Electric vehicles  because utilities have no knowledge of number of such vehicles in a particular geography and at what time of the day these will be charged

• Spikes in electricity demand can result due to concurrent charging patterns, sometimes leading to neighborhood blackouts

• Meeting unplanned demand will require increase in financial, operational, field and planning resources

• New services have to be introduced like public charging outlets and may have to be tied back to billing systems
  

• Extra meters with line infrastructure and field personal may have be deployed to install dedicated meters in garage / parking areas

• Standard household rates may not be valid for Electric Vehicles charging. Higher or different rates for Electric Vehicles may be required by some utilities or regulations

• Changes may be required in bill print to show separate consumption for Electric Vehicles charging from regular household use

While the above are significant challenges posed by growing use of electric vehicles, there are possible solutions for utilities that are running SAP or planning to implement SAP based solutions.

• Identifying additional demand and consumption requirements due to Electric vehicle use is important. Utilities can reach out to customers to understand their interest in Electric Vehicles and whether they are planning to purchase an electric vehicle in near future. The earlier the customers notify the utility, the more effective demand planning would be possible. This solution can be achieved in SAP in multiple ways:

1. This communication can be created as a campaign in SAP Customer Relationship Management with a preselected target group. Based on the response the campaign effectiveness can be analyzed and reported. Further campaigns can then be modified accordingly.
2. Bill Inserts via SAP Print Workbench or SAP certified products like StreamServe can help reach out to customers to gauge their interest in Electric Vehicles
3. With SAP UCES, customer feedback can be recorded when the customer logs into the online portal
   

• Utilities can tie up with Electric Vehicle dealers/sellers in their geography to notify the utility on sale of Electric Vehicles per geography. Using SAP, an Idoc based integration can be achieved with the Electric Vehicles dealer/Seller sending out a message with details of customer who has purchased the vehicle and his address . The same customer's details can be updated with relevant information in the SAP Master Data if it is also the utility's end customer.

• Some utilities may want to have differential rates and tariff for Electric Vehicle charging. Using SAP's IS-Utilities Billing module will allow to setup differential tariff for such cases. SAP IS-Utilities Work Management and Device Management modules will allow a separate meter installation and dedicated meter reading management. Utilities may recover the costs involved in additional meter installation from the customer. This cost can be integrated into the regular periodic bill by using SAP's Sales and Distribution Module and IS-Utilities Invoicing.

• Customer awareness campaigns can be executed to educate customers on charging their Electric Vehicles at off-peak hours. This can again be achieved using SAP CRM Campaign Management, Bill Inserts via SAP Print Workbench or StreamServe and SAP UCES.

• Electric Vehicles can also be integrated into the Smart Grid. With this integration, utilities will have the ability to remotely disconnect Electric Vehicle charging to reduce peak load on the local distribution infrastructure. This solution can be achieved with SAP IS-Utilities AMI integration pack of AMI where remote disconnection services are provided.

• Increasing outlets for public charging of electric vehicles will allow utilities to closely track and monitor growth and usage of electric vehicles in a geography. With SAP's Enterprise Asset Management modules, utilities can perform the entire blueprint to construction to maintenance of such charging outlets.

• A customer using a charging outlet can input his Customer or Account Number prior to charging. With SAP Mobility solutions these charging outlets can be integrated to SAP IS-Utilities Device Management modules to capture consumption and the same can be billed and included in the periodic bill of that customer.

• SAP Print Workbench and StreamServe can be used to enhance customer bill print by showing separate consumption and billing line items for electric vehicle usage.

• SAP BI can be used to generate business reporting for electric vehicles. Some of relevant reports can provide insights into revenue by EV consumption, penetration of Electric Vehicles, forecast in growth of Electric Vehicles, Charging station utilization etc.

While Electric Vehicle challenges will continue to grow, with SAP based solutions, utilities should be able to address these challenges in a more effective and organized way and for a much longer term without having to incur significant significantly or bringing in 3rd party solutions.

Posted by Parmarth Naswa at 2:28 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )