The What, Why, and How of Master Data Management - Part 1 - By Microsoft

Introduction

The pain that organizations are experiencing around consistent reporting, regulatory compliance, strong interest in Service-Oriented Architecture (SOA), and Software as a Service (SaaS) has prompted a great deal of interest in Master Data Management (MDM). This paper explains what MDM is, why it is important, and how to manage it, while identifying some of the key MDM management patterns and best practices that are emerging. This paper is a high-level treatment of the problem space. In subsequent papers, we will drill down into the technical and procedural issues involved in Master Data Management.

What Is Master Data?

Most software systems have lists of data that are shared and used by several of the applications that make up the system. For example, a typical ERP system as a minimum will have a Customer Master, an Item Master, and an Account Master. This master data is often one of the key assets of a company. It's not unusual for a company to be acquired primarily for access to its Customer Master data.

Rudimentary Definitions

There are some very well-understood and easily identified master-data items, such as "customer" and "product." In fact, many define master data by simply reciting a commonly agreed upon master-data item list, such as: customer, product, location, employee, and asset. But how you identify elements of data that should be managed by a master-data management system is much more complex and defies such rudimentary definitions. In fact, there is a lot of confusion around what master data is and how it is qualified, necessitating a more comprehensive treatment.

There are essentially five types of data in corporations:

• Unstructured - This is data found in e-mail, white papers like this, magazine articles, corporate intranet portals, product specifications, marketing collateral, and PDF files.
• Transactional - This is data related to sales, deliveries, invoices, trouble tickets, claims, and other monetary and non-monetary interactions.
• Metadata - This is data about other data and may reside in a formal repository or in various other forms such as XML documents, report definitions, column descriptions in a database, log files, connections, and configuration files.
• Hierarchical - Hierarchical data stores the relationships between other data. It may be stored as part of an accounting system or separately as descriptions of real-world relationships, such as company organizational structures or product lines. Hierarchical data is sometimes considered a super MDM domain, because it is critical to understanding and sometimes discovering the relationships between master data.
• Master - Master data are the critical nouns of a business and fall generally into four groupings: people, things, places, and concepts. Further categorizations within those groupings are called subject areas, domain areas, or entity types. For example, within people, there are customer, employee, and salesperson. Within things, there are product, part, store, and asset. Within concepts, there are things like contract, warrantee, and licenses. Finally, within places, there are office locations and geographic divisions. Some of these domain areas may be further divided. Customer may be further segmented, based on incentives and history. A company may have normal customers, as well as premiere and executive customers. Product may be further segmented by sector and industry. The requirements, life cycle, and CRUD cycle for a product in the Consumer Packaged Goods (CPG) sector is likely very different from those of the clothing industry. The granularity of domains is essentially determined by the magnitude of differences between the attributes of the entities within them.

Deciding What to Manage

While identifying master data entities is pretty straightforward, not all data that fits the definition for master data should necessarily be managed as such. This paper narrows the definition of master data to the following criteria, all of which should be considered together when deciding if a given entity should be treated as master data.

Behavior

Master data can be described by the way that it interacts with other data. For example, in transaction systems, master data is almost always involved with transactional data. A customer buys a product. A vendor sells a part, and a partner delivers a crate of materials to a location. An employee is hierarchically related to their manager, who reports up through a manager (another employee). A product may be a part of multiple hierarchies describing their placement within a store. This relationship between master data and transactional data may be fundamentally viewed as a noun/verb relationship. Transactional data capture the verbs, such as sale, delivery, purchase, email, and revocation; master data are the nouns. This is the same relationship data-warehouse facts and dimensions share.

Life Cycle

Master data can be described by the way that it is created, read, updated, deleted, and searched. This life cycle is called the CRUD cycle and is different for different master-data element types and companies. For example, how a customer is created depends largely upon a company's business rules, industry segment, and data systems. One company may have multiple customer-creation vectors, such as through the Internet, directly through account representatives, or through outlet stores. Another company may only allow customers to be created through direct contact over the phone with its call center. Further, how a customer element is created is certainly different from how a vendor element is created. The following table illustrates the differing CRUD cycles for four common master-data subject areas.

Cardinality

As cardinality (the number of elements in a set) decreases, the likelihood of an element being treated as a master-data element—even a commonly accepted subject area, such as customer—decreases. For example, if a company has only three customers, most likely they would not consider those customers master data—at least, not in the context of supporting them with a master-data management solution, simply because there is no benefit to managing those customers with a master-data infrastructure. Yet, a company with thousands of customers would consider Customer an important subject area, because of the concomitant issues and benefits around managing such a large set of entities. The customer value to each of these companies is the same. Both rely upon their customers for business. One needs a customer master-data solution; the other does not. Cardinality does not change the classification of a given entity type; however, the importance of having a solution for managing an entity type increases as the cardinality of the entity type increases.

Lifetime

Master data tends to be less volatile than transactional data. As it becomes more volatile, it typically is considered more transactional. For example, some might consider "contract" a master-data element. Others might consider it a transaction. Depending on the lifespan of a contract, it can go either way. An agency promoting professional athletes might consider their contracts as master data. Each is different from the other and typically has a lifetime of greater than a year. It may be tempting to simply have one master-data item called "athlete." However, athletes tend to have more than one contract at any given time: one with their teams and others with companies for endorsing products. The agency would need to manage all those contracts over time, as elements of the contract are renegotiated or athletes traded. Other contracts—for example, contracts for detailing cars or painting a house—are more like a transaction. They are one-time, short-lived agreements to provide services for payment and are typically fulfilled and destroyed within hours.

Complexity

Simple entities, even valuable entities, are rarely a challenge to manage and are rarely considered master-data elements. The less complex an element, the less likely the need to manage change for that element. Typically, such assets are simply collected and tallied. For example, Fort Knox likely would not track information on each individual gold bar stored there, but rather only keep a count of them. The value of each gold bar is substantial, the cardinality high, and the lifespan long; yet, the complexity is low.

Value

The more valuable the data element is to the company, the more likely it will be considered a master data element. Value and complexity work together.

Volatility

While master data is typically less volatile than transactional data, entities with attributes that do not change at all typically do not require a master-data solution. For example, rare coins would seem to meet many of the criteria for a master-data treatment. A rare-coin collector would likely have many rare coins. So, cardinality is high. They are valuable. They are also complex. For example, rare coins have a history and description. There are attributes, such as condition of obverse, reverse, legend, inscription, rim, and field. There are other attributes, such as designer initials, edge design, layers, and portrait.

Yet, rare coins do not need to be managed as a master-data item, because they don't change over time—or, at least, they don't change enough. There may need to be more information added, as the history of a particular coin is revealed or if certain attributes must be corrected. But, generally speaking, rare coins would not be managed through a master-data management system, because they are not volatile enough to warrant a solution.

Reuse

One of the primary drivers of master-data management is reuse. For example, in a simple world, the CRM system would manage everything about a customer and never need to share any information about the customer with other systems. However, in today's complex environments, customer information needs to be shared across multiple applications. That's where the trouble begins. Because—for a number of reasons—access to a master datum is not always available, people start storing master data in various locations, such as spreadsheets and application private stores. There are still reasons, such as data-quality degradation and decay, to manage master data that is not reused across the enterprise. However, if a master-data entity is reused in multiple systems, it's a sure bet that it should be managed with a master-data management system.

To summarize, while it is simple to enumerate the various master-data entity types, it is sometimes more challenging to decide which data items in a company should be treated as master data. Often, data that does not normally comply with the definition for master data may need to be managed as such, and data that does comply with the definition may not. Ultimately, when deciding on what entity types should be treated as master data, it is better to categorize them in terms of their behavior and attributes within the context of the business needs than to rely on simple lists of entity types.

Why Should I Manage Master Data?

Because it is used by multiple applications, an error in master data can cause errors in all the applications that use it. For example, an incorrect address in the customer master might mean orders, bills, and marketing literature are all sent to the wrong address. Similarly, an incorrect price on an item master can be a marketing disaster, and an incorrect account number in an Account Master can lead to huge fines or even jail time for the CEO—a career-limiting move for the person who made the mistake!

Here is a typical master-data horror story: A credit-card customer moves from 2847 North 9th St. to 1001 11th St. North. The customer changed his billing address immediately, but did not receive a bill for several months. One day, the customer received a threatening phone call from the credit-card billing department, asking why the bill has not been paid. The customer verifies that they have the new address, and the billing department verifies that the address on file is 1001 11th St. N. The customer asks for a copy of the bill, to settle the account. After two more weeks without a bill, the customer calls back and finds the account has been turned over to a collection agency. This time, they find out that even though the address in the file was 1001 11th St. N, the billing address is 101 11th St. N. After a bunch of phone calls and letters between lawyers, the bill finally gets resolved and the credit-card company has lost a customer for life. In this case, the master copy of the data was accurate, but another copy of it was flawed. Master data must be both correct and consistent.

Even if the master data has no errors, few organizations have just one set of master data. Many companies grow through mergers and acquisitions. Each company you acquire comes with its own customer master, item master, and so forth. This would not be bad if you could just Union the new master data with your current master data, but unless the company you acquire is in a completely different business in a faraway country, there's a very good chance that some customers and products will appear in both sets of master data—usually, with different formats and different database keys. If both companies use the Dun & Bradstreet number or Social Security number as the customer identifier, discovering which customer records are for the same customer is a straightforward issue; but that seldom happens. In most cases, customer numbers and part numbers are assigned by the software that creates the master records, so the chances of the same customer or the same product having the same identifier in both databases is pretty remote. Item masters can be even harder to reconcile, if equivalent parts are purchased from different vendors with different vendor numbers.

Merging master lists together can be very difficult. The same customer may have different names, customer numbers, addresses, and phone numbers in different databases. For example, William Smith might appear as Bill Smith, Wm. Smith, and William Smithe. Normal database joins and searches will not be able to resolve these differences. A very sophisticated tool that understands nicknames, alternate spellings, and typing errors will be required. The tool will probably also have to recognize that different name variations can be resolved, if they all live at the same address or have the same phone number. While creating a clean master list can be a daunting challenge, there are many positive benefits to your bottom line from a common master list:

• A single, consolidated bill saves money and improves customer satisfaction.
• Sending the same marketing literature to a customer from multiple customer lists wastes money and irritates the customer.
• Before you turn a customer account over to a collection agency, it would be good to know if they owe other parts of your company money or, more importantly, that they are another division's biggest customer.
• Stocking the same item under different part numbers is not only a waste of money and shelf space, but can potentially lead to artificial shortages.

The recent movements toward SOA and SaaS make Master Data Management a critical issue. For example, if you create a single customer service that communicates through well-defined XML messages, you may think you have defined a single view of your customers. But if the same customer is stored in five databases with three different addresses and four different phone numbers, what will your customer service return? Similarly, if you decide to subscribe to a CRM service provided through SaaS, the service provider will need a list of customers for their database. Which one will you send them?

For all these reasons, maintaining a high-quality, consistent set of master data for your organization is rapidly becoming a necessity. The systems and processes required to maintain this data are known as Master Data Management.

Continue : Part 2 - What is Master Data Management? & Conclusion

Data Migration Overview - By Javlin Data Solutions

Data Migration is the process of transferring data from one system to another while changing the storage, database or application. In reference to the ETL (Extract-Transform-Load) process, data migration always requires at least Extract and Load steps.

Typically data migration occurs during an upgrade of existing hardware or transfer to a completely new system. Examples include: migration to or from hardware platform; upgrading a database or migrating to new software; or company-mergers when the parallel systems in the two companies need to be merged into one. There are three main options to accomplish data migration:

1. Merge the systems from the two companies into a brand new one.
2. Migrate one of the systems to the other one.
3. Leave the systems as they are but create a common view on top of them - a data warehouse.

Data Migration Challenges

Let us describe the data migration challenges in little more detail. Data migration can be a simple process, however there are challenges one may face in implementation.

#Storage Migration
Storage migration can be handled in a manner transparent to the application so long as the application uses only general interfaces to access the data. In most systems this is not an issue. However, careful attention is necessary for old applications running on proprietary systems. In many cases, the source code of the application is not available and the application vendor may not be in market anymore. In such cases storage migration is rather tricky and should be properly tested before releasing the solution into production.

#Database Migration

Database migration is rather straight forward, assuming the database is used just as storage. It "only" requires moving the data from one database to another. However, even this may be a difficult task. The main issues one may encounter include:

1. Unmatched data types (number, date, sub-records)
2. Different character sets (encoding)

Different data types can be handled easily by approximating the closest type from the target database to maintain data integrity. If a source database supports complex data formats (e.g. sub-record), but the target database does not, amending the applications using the database is necessary. Similarly, if the source database supports different encoding in each column for a particular table but the target database does not, the applications using the database need to be thoroughly reviewed.

When a database is used not just as data storage, but also to represent business logic in the form of stored procedures and triggers, close attention must be paid when performing a feasibility study of the migration to target database. Again, if the target database does not support some of the features, changes may need to be implemented by applications or by middleware software.

ETL tools are very well suited for the task of migrating data from one database to another i. Using the ETL tools is highly advisable particularly when moving the data between the data stores which do not have any direct connection or interface implemented.

#Application Migration
If we take a step back to previous two cases, you may notice that the process is rather straight forward. This however, is extremely uncommon in the case of application migration. The reason is that the applications, even when designed by the same vendor, store data in significantly different formats and structures which make simple data transfer impossible. The full ETL process is a must as the Transformation step is not always straight forward. Of course, application migration can and usually does include storage and database migration as well. The advantage of an ETL tool in this instance is its ready-to-use connectivity to disparate data sources/targets.

Difficulty may occur when migrating data from mainframe systems or applications using proprietary data storage. Mainframe systems use record based formats to store data. Record based formats are easy to handle; however, there are often optimizations included in the mainframe data storage format which complicate data migration. Typical optimizations include binary coded decimal number storage, non-standard storing of positive/negative number values, or storing the mutually exclusive sub-records within a record. Let us consider a library data warehouse as an example. There are two types of publications - books and articles. The publication can be either a book or an article but not both. There are different kinds of information stored for books and articles. The information stored for a book and an article are mutually exclusive. Hence, when storing a book, the data used has a different sub-record format for a book and an article while occupying the same space. Still the data is stored using rather standard encoding. On the Contrary, proprietary data storage makes the Extract step even more complicated. In both cases, the most efficient way to extract data from the source system is performing the extraction in the source system itself; then converting the data into a printable format which can be parsed later using standard tools.

#Character Encoding
Most of the systems developed on PC-based platform use ASCII encoding or national extension based on ASCII. The latest one is UTF-8 which keeps ASCII mapping for alpha and numerical characters but enables storage of characters for most of the national alphabets including Chinese, Japanese and Russian. Mainframe systems are mostly based on EBCDIC encoding which is incompatible with ASCII and conversion is required to display the data. ETL tools should support the conversions between character sets, including EBCDIC.

...

Source : DataIntegration.Info (Javlin - Data Solutions)

Master Data Management - By Javlin Data Solutions

Master Data Management (MDM) represents a set of tools and processes used by an enterprise to consistently manage their non-transactional data. MDM is usually applied to entities like Customer, Client, Product, Account and internal reference data. MDM also enables easy maintenance of data lineage and history for audit purposes.

Issues

In the enterprise there are several systems managing the same data; the role of MDM is to centralize the data management to only one master copy of the data item which is then synchronized to all applications using the data. Using this approach, when referring to (for example) a customer within the enterprise, all systems are referring to the same customer.

There are basically two reasons why there are duplicated data which are inconsistent:

• The production systems within an enterprise, when implemented, have not been designed to be a part of larger set of production systems with which they should cooperate. Therefore, each system manages data on its own.
• The branches or departments of the company exist on their own without close cooperation with other departments. For example, the mortgage department deals with customers and manages the mortgage contracts. While the marketing department plans a promotion on mortgages. If the two departments do not cooperate (share the data), the marketing department may offer a mortgage to a customer who already has a mortgage. This is both a waste of money on the promotion as well as annoying to the customer.
• Company acquisitions or mergers are another example when an enterprise gets several parallel systems managing similar and sometimes overlapping data.

Solutions

To handle the issues mentioned above, the common baseline for Master Data Management solutions comprises the following processes:

• Source identification - the 'system of record' needs to be identified first. If the same record is stored in multiple systems, the system which holds the most relevant copy (most valid, actual, or complete) of that record is referred to as a 'system of record'.
• Data collection - the data needs to be collected from various sources as some sources may attach a new piece of information, while dropping pieces which they are not interested in.
• Transformation - the transformation step takes place both during the input, while data are converted into a format for MDM processing, as well as on the output when distributing the master records back to the particular systems and applications.
• Data consolidation - the records from various systems which represent the same physical entity are consolidated into one record - a master record. The record is assigned a version number to enable a mechanism to check which version of record is being used in particular systems.
• Data deduplication - often there are separate records in the company's systems, which in fact identify the same customer. For example, the bank may have a record identifying a customer while the bank's insurance subsidiary or department maintains a separate database of customers having a different record for the same customer. It is vital that these two records are deduplicated and maintained as one master record.
• Error detection - based on the rules and metrics, the incomplete records or records containing inconsistent data should be identified and sent to their respective owners before publishing them to all the other applications. Providing erroneous data may compromise credibility of the company's MDM.
• Data correction - related to error detection, this step notifies the owner of the data record that there is a need to review the record manually.
• Data distribution/synchronization - the master records are distributed to the systems in the enterprise. The goal is that all the systems are using the same version of the record as soon as possible after the publication of the new record.

Process

In the previous paragraphs, we have mentioned that each data record has to be assigned its owner or steward - a person who understands the data and is responsible for maintaining the record. The steward needs to be from the business side of the company. The reason, of course, is that only a business person understands the data and can make decisions about the data consolidation, updates, corrections and validity. On the other hand, the actual processing can be made available to either the business user via GUI or the IT department.

...

Source : DataIntegration.Info (Javlin - Data Solutions)

Data Integration Overview - By Javlin Data Solutions

Data integration involves combining data from several disparate sources, which are stored using various technologies and provide a unified view of the data. Data integration becomes increasingly important in cases of merging systems of two companies or consolidating applications within one company to provide a unified view of the company's data assets. The later initiative is often called a data warehouse.

Probably the most well known implementation of data integration is building an enterprise's data warehouse. The benefit of a data warehouse enables a business to perform analyses based on the data in the data warehouse. This would not be possible to do on the data available only in the source system. The reason is that the source systems may not contain corresponding data, even though the data are identically named, they may refer to different entities.

Data Integration Areas

Data integration is a term covering several distinct sub-areas such as:

• Data Warehousing
• Data Migration
• Enterprise Application / Information Integration
• Master Data Management

This article concentrates on the process of data integration. More detailed information about the above areas can be found in related articles.

Challenges of Data Integration

At first glance, the biggest challenge is the technical implementation of integrating data from disparate often incompatible sources. However, a much bigger challenge lies in the entirety of data integration. It has to include the following phases:

#Design

• The data integration initiative within a company must be an initiative of business, not IT. There should be a champion who understands the data assets of the enterprise and will be able to lead the discussion about the long-term data integration initiative in order to make it consistent, successful and benefitial.
• Analysis of the requirements (BRS : Business Requirement Specification), i.e. why is the data integration being done, what are the objectives and deliverables. From what systems will the data be sourced? Is all the data available to fulfill the requirements? What are the business rules? What is the support model and SLA?
• Analysis of the source systems, i.e. what are the options of extracting the data from the systems (update notification, incremental extracts, full extracts), what is the required/available frequency of the extracts? What is the quality of the data? Are the required data fields populated properly and consistently? Is the documentation available? What are the data volumes being processed? Who is the system owner?
• Any other non-functional requirements such as data processing window, system response time, estimated number of (concurrent) users, data security policy, backup policy.
• What is the support model for the new system? What are the SLA requirements?
• And last but not least, who will be the owner of the system and what is the funding of the maintenance and upgrade expenses?
• The results of the above steps need to be documented in form of SRS (System Requirement Specification) document, confirmed and signed-off by all parties which will be participating in the data integration project.

#Implementation

Based on the BRS and SRS, a feasibility study should be performed to select the tools to implement the data integration system. Small companies and enterprises which are starting with data warehousing are faced with making a decision about the set of tools they will need to implement the solution. The larger enterprise or the enterprises which already have started other projects of data integration are in an easier position as they already have experience and can extend the existing system and exploit the existing knowledge to implement the system more effectively. There are cases, however, when using a new, better suited platform or technology makes a system more effective compared to staying with existing company standards. For example, finding a more suitable tool which provides better scaling for future growth/expansion, a solution that lowers the implementation / support cost, lowering the license costs, migrating the system to a new/modern platform, etc.

#Testing

Along with the implementation, the proper testing is a must to ensure that the unified data are correct, complete and up-to-date.

Both technical IT and business needs to participate in the testing to ensure that the results are as expected/required. Therefore, the testing should incorporate at least Performance Stress test (PST), Technical Acceptance Testing (TAT) and User Acceptance Testing (UAT ) PST, TAT (Technical Acceptance Testing), UAT (User Acceptance Testing).

Data Integration Techniques

There are several organizational levels on which the integration can be performed. As we go down the level of automated integration increases.

Manual Integration or Common User Interface - users operate with all the relevant information accessing all the source systems or web page interface. No unified view of the data exists.

Application Based Integration - requires the particular applications to implement all the integration efforts. This approach is manageable only in case of very limited number of applications. 

• Extra from Ebizq : Fundamentally, Application Integration links multiple applications together at the functional level. It deals with things at the transactional or service-call level. It is "aware" of how different pieces of information (such as the creation of a new customer) come together to create one atomic unit that cannot be subdivided without introducing data inconsistencies (i.e. "corruption") into the system. Furthermore Application Integration systems are typically event-based in nature - that is to say, as soon as "something happens" in the originating application, like the creation of a new customer, the transaction is sent over to the destination application(s). The goal is to do this in "real-time", so that multiple systems are always synchronized. 
• Extra from Mulesoft : Application Integration, on the other hand, deals with integrating live operational data in real-time between two or more applications. Typically an “event” will occur. For instance, when a customer places an order, this triggers an integration flow that updates and enriches data in other applications in real-time.
  

Middleware Data Integration - transfers the integration logic from particular applications to a new middleware layer. Although the integration logic is not implemented in the applications anymore, there is still a need for the applications to partially participate in the data integration. 

• Extra from Tech Republic : Middleware is software that lets systems talk to one another while hiding the complexities of network connectivity. Middleware is an important data warehouse component since it's the means by which applications communicate with the data warehouse. Middleware technology lets clients talk to servers, but more critically, it shields the application programmer from the complexity of finding and combining data. Middleware exists for transactional systems, communications systems, and data warehouses. Database middleware, the type used for data warehouses, connects the data warehouse to client applications as part of either a two- or three tier architecture.

Uniform Data Access or Virtual Integration - leaves data in the source systems and defines a set of views to provide and access the unified view to the customer across whole enterprise. For example, when a user accesses the customer information, the particular details of the customer are transparently acquired from the respective system. The main benefits of the virtual integration are nearly zero latency of the data updates propagation from the source system to the consolidated view, no need for separate store for the consolidated data. However, the drawbacks include limited possibility of data's history and version management, limitation to apply the method only to 'similar’ data sources (e.g. same type of database) and the fact that the access to the user data generates extra load on the source systems which may not have been designed to accommodate.

Common Data Storage or Physical Data Integration - usually means creating a new system which keeps a copy of the data from the source systems to store and manage it independently of the original system. The most well know example of this approach is called Data Warehouse (DW). The benefits comprise data version management, combining data from very different sources (mainframes, databases, flat files, etc.). The physical integration, however, requires a separate system to handle the vast volumes of data. 

...

Source : DataIntegration.Info (Javlin - Data Solutions)

9 Building Blocks of Business Model Sebagai Acuan Membuat Rencana Bisnis

Membuka bisnis memang memerlukan keberanian, namun membuka bisnis juga memerlukan perhitungan yang matang. Sehingga resiko apapun yang muncul dapat di manage dengan baik.

Salah satu cara termudah menyiapkan rencana bisnis adalah membuat “kerangka” atau building block yang terintegrasi dengan baik.

Dalam bukunya “Business Model Generation” – Alex Osterwalder menuliskan 9 building block yang bisa kita jadikan acuan untuk membuat rencana bisnis kita.

1. Mengetahui Pelanggan Anda

Apakah anda sudah mengetahui dengan persis siapa calon pelanggan anda? Jawablah pertanyaan-pertanyaan dibawah ini:

• Berapa umur mereka?
• Apa jenis kelamin mereka?
• Dimana mereka tinggal ?
• Apa yang menjadi kebutuhan mereka?
• Berapa pengeluaran mereka perbulan?

Jika anda bisa menjawab pertanyaan-pertanyaan di atas berarti anda sudah siap menjawab pertanyaan penting berikut: produk atau layanan apa yang akan anda sediakan bagi calon pelanggan anda?

Kesalahan yang biasa dilakukan oleh pebisnis pemula adalah langsung menentukan bisnis dan baru memutuskan siapa yang bisa dijual.

2. Apa yang Anda Tawarkan Dalam Bisnis ?

Inilah hal utama yang anda tawarkan kepada pelanggan anda di atas. Tentukan bisnis anda untuk menjawab masalah yang dihadapi konsumen. Jenis usaha apa yang bisa menjawab kebutuhan di atas?

Jika pelanggan memerlukan makanan, anda bisa membuka restaurant. Jika pelanggan memerlukan berita, anda bisa membuka bisnis media. Jika pelanggan sangat peduli dengan pendidikan anaknya anda bisa membuka bisnis kursus privat.

3. Saluran Distribusi

Apapun bisnis yang anda putuskan, anda harus menentukan saluran penjualan, bagaimana cara agar produk/layanan anda sampai ke pelanggan anda.

Apakah anda akan membangun tim penjualan sendiri? Atau akan memberikan bagian penjualan kepada orang lain seperti distributor? Apakah anda akan membuka toko sendiri? Atau membuka counter kecil di dalam toko besar seperti Matahari? Apakah anda akan menjual secara online atau membuka toko?

Analisa kelebihan dan kekurangan dari setiap pilihan anda di atas, lalu pilih yang terbaik

4. Marketing

Sebuah bisnis baru harus diketahui oleh calon pelanggan kita, karena itu kita perlu “menyuarakannya kepada publik”. Berbagai cara bisa anda lakukan, baik online maupun offline. Kegiatan offline adalah kegiatan yang bersifat fisik, misalnya mengadakan event atau gathering, membagikan brosur, memasang spanduk atau baliho di jalan.

Saat ini kegiatan marketing online adalah kegiatan favorit para pemula bisnis, karena budget yang relatif kecil bahkan seringkali gratis. Kegiatan marketing online antara lain adalah membuat blog, menggunakan facebook atau twitter, hingga memasang iklan di Google Adwords

5.  Pendapatan

Dari semua hal di atas, ini merupakan building block yang paling penting. Bagaimana rencana anda untuk memperoleh penghasilan? Banyak bisnis yang dibuat tanpa tahu bagaimana memperoleh penghasilannya dan ini sangat berbahaya bagi bisnis.

Sejak awal, tentukan jenis-jenis pendapatan anda. Apakah anda akan membuat media online dan mendapatkan pendapatan dari iklan? Apakah anda akan membuat toko dan mendapat penghasilan dari volume penjualan? Apakah anda akan membuat perusahaan design lalu mendapatkan fee design? Putuskan dan tentukan target pendapatan per bulan.

Jangan pernah membuat bisnis tanpa memikirkan rencana pendapatan dan berpikir: “lihat aja nanti dapat duit darimana”

6. Key Partners

Sukses berbisnis tidak bisa sendirian, anda harus bekerjasama dengan banyak pihak lainnya. Tentukan dari awal apakah bisnis anda memerlukan investor untuk permodalan atau tidak. Apakah anda perlu mengadakan perjanjian kerjasama khusus dengan distributor? Apakah anda perlu mendapatkan endorsement dari “selebriti” dan memberikan persentase saham kepada selebriti tersebut?

Menggandeng partner yang melengkapi kemampuan yang kita miliki akan meningkatkan peluang keberhasilan bisnis. Misalnya, anda sangat ahli membuat makanan yang enak, cari partner yang bisa menjual makanan anda (marketing). Misalnya anda kenal distributor suatu produk yang lebih murah, cari partner yang bisa membuat website, untuk dijual online.

Pikirkan untuk menjalin kolaborasi dengan partner.

7.  Kegiatan Bisnis

Kegiatan-kegiatan apa saja yang akan anda lakukan untuk menghasilkan uang?
Apakah anda akan mengadakan event, mengumpulkan uang lalu mendapatkan dana dari sponsor? Apakah anda akan mengadakan kursus web design yang akan berlangsung setiap hari?

8. Sumber Daya

Membuat dan menjalankan bisnis umumnya tidak bisa sendirian. Anda memerlukan staff. Sejak awal tentukan berapa banyak dan jenis keahlian apa yang diperlukan oleh karyawan anda? Misalnya dalam sebuah toko: berapa banyak tenaga sales diperlukan? Berapa banyak tenaga kasir diperlukan? Berapa banyak tenaga administrasi seperti accounting diperlukan?

Selain staff/SDM, anda juga memerlukan sumber daya non manusia. Berapa sewa toko/kantor perbulan? Berapa komputer dan berapa harga totalnya? Apakah anda perlu membuat meja counter atau display untuk penjualan.

9. Biaya

Semua hal yang dilakukan dari poin nomor 6 hingga 9 memerlukan biaya, lakukan perhitungan secara seksama, lalu putuskan apakah rencana rencana bisnis anda menguntungkan?
Mengetahui menguntungkan/tidaknya sebenarnya sederhana saja kok: apakah penghasilan anda lebih besar dari pengeluaran? Jika tidak berarti anda akan merugi dan bisnis ini tidak layak dijalankan.

Kami sarankan hanya jalankan bisnis yang “profitable di atas kertas”. Namun satu hal yang paling penting, bisnis tidak berjalan di atas kertas. Action! Langkah nyata pertama anda itulah yang akan menentukan berjalan/tidaknya bisnis Anda.

Artikel ini memberikan gambaran singkat mengenai apa saja yang harus anda persiapkan sebelum memulai bisnis, sementara detailnya masing-masing akan kami tuliskan kemudian secara berkala dalam judul yang berbeda-beda.

Sumber : Startup Bisnis

Extra : Video Youtube 

Hari Menyebalkan di Tempat Anda Berada

Alkitab mengajarkan kita mengasihi sesama maupun musuh kita, karena kemungkinan mereka adalah orang yang sama (G.K. Chesteron)

Anda memedulikan rekan kerja Anda atau tetangga Anda dan mereka pun peduli dengan Anda. Alkitab banyak berkata tentang berhubungan dengan orang-orang yang menyulitkan. 

Roma 12:20

"Tetapi, jika seterumu lapar, berilah dia makan; jika ia haus, berilah dia minum! Dengan berbuat demikian kamu menumpukkan bara api di atas kepalanya.”

Sekalipun agak lama, namun pada akhirnya mereka akan mengakui sikap baik Anda dan memuji Allah. Itulah alasan Yesus berkata : “kasihilah sesamamu dan berdoalah bagi orang yang menganiyamu” (Mat 5:43-48)

Mungkin sulit diakui dan dilakukan, namun Allah juga mengasihi musuh anda sebagaimana Dia mengasihi anda. Disamping itu kita semua bukanlah manusia sempurna. Kita sering kali melakukan kesalahan. Itulah hakikat kedosaan manusia.

Sebagai murid Yesus, kita harus senantiasa bersikap baik dan benar. Namun saat kita gagal, kita harus menjadi pihak pertama yang meminta maaf dan berusaha keras memperbaikinya. Kesaksian hidup kita bergantung pada hal ini.

So, Jangan pernah memberikan kesempatan bagi orang tidak percaya untuk melihat Anda sebagai orang munafik.

Bapa Surgawi, sebagaimana orang Samaria yang baik hati, bantulah aku untuk melihat orang yang membutuhkan dan menolongnya. Bantu aku agar dapat mengasihi rekan kerjaku sekalipun ia menyebalkan. Bantulah aku agar bersinar sehingga orang lain terpikat padaMu. Amin.

1 Petrus 2:12

Milikilah cara hidup yang baik di tengah-tengah bangsa-bangsa bukan Yahudi, supaya apabila mereka memfitnah kamu sebagai orang durjana, mereka dapat melihatnya dari perbuatan-perbuatanmu yang baik dan memuliakan Allah pada hari Ia melawat mereka.

Sumber : Agus Gunawan (Chief HCM - PT AGIT - Via Email Blast 16 Juni 2014)

Akar Segala Kejahatan Ialah Cinta Uang

Tahukah Anda Alkitab memiliki sekitar :

• 600an ayat tentang Iman
• 300an ayat tentang Doa
• 900an ayat tentang Uang, Harta, Kekayaan

Berikut adalah contoh ayatnya :

Timotius 6:10
Karena akar segala kejahatan ialah cinta uang. Sebab oleh memburu uanglah beberapa orang telah menyimpang dari iman dan menyiksa dirinya dengan berbagai-bagai duka.

Lukas 12:34
Karena di mana hartamu berada, di situ juga hatimu berada.

Pengkotbah 5:9
Siapa mencintai uang tidak akan puas dengan uang, dan siapa mencintain kekayaan tidak akan puas dengan penghasilannya. Ini pun sia-sia.

Alkitab sendiri tidak pernah mengatakan bahwa uang itu sendiri buruk. Cinta akan uang itu yang buruk, berusaha kaya dengan cepat itu yang buruk. Untuk menghentikan cekikan uang pada diri kita, kita perlu mengenali sifat dasar kepemilikan. Barang duniawi tidaklah kekal, semua kekayaan yang kita miliki hanya pinjaman dari pemilik-nya. Bersyukurlah selalu dan selalu berdoa : "Berikanlah kami pada hari ini makan kami yang secukupnya"

Bapa Surgawi, aku tahu aku tidak pernah dapat melayani-Mu dengan segenap hatiku, hingga ku berhenti mengejar kepemilikan materi. Bantulah aku melonggarkan cengkramanku pada uang. Bantulah aku melayani dengan semua kekayaan yang telah Engkau berikan kepadaku. Bukalah mataku dan lunakkan hatiku, sehingga aku dapat melayani-Mu dengan segenap hatiku ditempat dimana aku berkarya. Amin.
 

Matius 6:19

Janganlah kamu mengumpulkan harta di bumi; di bumi ngengat dan karat merusakkannya dan pencuri membongkar serta mencurinya.

Sumber : Agus Gunawan (Chief HCM - PT AGIT - Via Email Blast 26 Mei 2014)

Business Analyst vs System Analyst - Differences and Similarities - By Villanova University

The terms “business analyst” and “business system analyst” are often used interchangeably to describe the same job. But the two are actually completely different positions, with distinct descriptions and duties. Here, we’ll explain the differences between business analysts and systems analysts, as well as a few commonalities the two professions share.

What Does a Business Systems Analyst Do?

Systems analysts utilize an organization’s IT systems to help achieve strategic business goals. They may design and develop new systems by configuring new hardware and software, or use existing systems in new ways to accomplish additional or different outcomes.

Typical tasks performed by systems analysts include:

• Consulting with management and users to determine the needs of the system.
• Designing a system to meet the business goals.
• Specifying inputs and formatting outputs to meet users’ needs.
• Using techniques such as sampling, model building and structured analysis, along with accounting principles, to ensure the solution is efficient, cost-effective and financially feasible.
• Developing specifications, diagrams and flowcharts for programmers to follow.
• Overseeing implementation, coordinating tests and observing initiation of the system to validate performance

Education and Training Required for Business Systems Analysts

Most employers will look for at least a bachelor’s degree when hiring systems analysts, typically in a technical field such as computer science, information technology, engineering or information systems. However, some prefer a business background combined with computer skills. Others seek industry-related experience, such as finance, telecommunications or healthcare, along with technical skills.

In general, the systems analyst job requires more in-depth technical knowledge, while the business analyst position requires a better understanding of the complexities of business problems and using technology to solve them.

What Does a Business Analyst Do?

Business analysts generally possess technical knowledge as well. Their main focus is identifying opportunities for improving a business’s processes and using technology to eliminate problems that affect productivity, output, distribution and ultimately, the bottom line. So, knowing how technology can solve business problems is vital to a business analyst’s success. These professionals require a high degree of specialized skills in order to solve business problems through a variety of typical job duties, including:

• Analyzing the business processes in an organization for inefficiencies.
• Making recommendations for solutions or improvements that can be accomplished through new technology or alternative uses of existing technology.
• Acting as liaison between business stakeholders, such as management, customers or end users, and the software development or information technology team.
• Analyzing and communicating stakeholder needs by translating business requirements into software requirements.
• Documenting and evaluating required data and information.
• Using modeling, testing and data models to improve the flow of information through an organization to enhance project success.

Education and Training Required for Business Analysts

Becoming a successful business analyst takes a special combination of technical skill and business acumen, along with a high degree of confidence – usually acquired as a result of proper education, business analysis training and experience. Many professional business analysts break into the field by earning a degree in information technology, business administration, finance or a related area, or by working in human resources, management or finance, and then pursuing specialized training. Industry certifications, such as the Certified Business Analysis Professional (CBAP®) designation by the International Institute of Business Analysis (IIBA®), are becoming more valuable, as employers increasingly demand these respected credentials.

Skills and Attributes Required for Both Business Analysts and Systems Analysts

Strong problem-solving and analytical skills, communication and interpersonal skills, and the ability to focus with close attention to detail are required in both the business analyst and systems analyst professions. A business analyst needs a broad base of business knowledge and sharply honed essential skills, while the systems analyst’s skill set is more technology-specific.

Outlook and Salary for Business Analysis and Systems Analyst Jobs

The Bureau of Labor Statistics predicts both the business analyst and systems analyst fields will expand employment in years to come – and much faster than most other job categories. Job opportunities should be excellent. Still, competition for these positions will be tough, partly because of the high salaries earned. The BLS reports that in May 2010 the average salary for systems analysts was $81,250, while management/business analysts annual salaries came in at $87,260 on average in May 2010*.

A Systems Analyst is Not the Same as a Business Analyst

While there are some common skills and knowledge requirements between systems analysts and business analysts, the business analyst profession requires an entirely different set of core specialty skills involving eliciting, analyzing, communicating, testing and verifying requirements, plus the ability to identify opportunities to solve business problems and improve processes. Business analysts are functional experts who work for change and improvement, helping organizations reach their strategic goals through continual, successful technology improvements.

Original Source

Villanova University

Women's Dictionary and Uniqueness

Things Women Say >>> What They Really Mean

Hmm... >>> I'm jealous

I see >>> I don't believe you

Ok >>> Shut up

Everything is fine >>> Everything is wrong

Go >>> Don't go

Nevermind >>> You don't understand

Good >>> I'm angry

Do whatever you want >>> If you do it, it's over

No >>> Yes

Yes >>> Maybe

Maybe >>> No

 

Those sentences and picture above might be just some pieces of woman's "uniqueness". We (man) face it a lot everyday. We (man) should be careful and clever when respond to woman's words. It's like a hidden bomb that ready to explode when we respond it with man's mindset. No offense for woman, we just want to understand more about you. :)

...

“Women and cats will do as they please, and men and dogs should relax and get used to the idea.”
-Robert A. Heinlein-

Just Do It - Stop Being Afraid & Worried

Today is my first day my role becomes Business Development. Finally the time has come, and I have to face a new life with a new job. At least, I have prepared for this since last month. You guys can read the intro of this story here. I'm glad that I can through this day with smoothly. My new colleagues seems accept me as a new member in the environment. I believe that everything will be okay. I won't let my concern bother me.

Stop being afraid on what could go wrong and focus on what could go right.

To be honest, I was afraid of being failed here. And when it haunt my life, I couldn't think clearly. Challenges come everyday even though I wasn't choose this path. I know that everything come for a reason and I should focus on what lies ahead.

Do no waste time thinking about what could have been, because you may miss out on what could be.

Worrying is a waste of time. It doesn't change anything. It messes with your mind and steals your happiness. 

We could miss out on what could be when we often look backward and think what could have been. We couldn't change the past and choose another option. It will be useless, time will disappeared and steal our happiness. Believe that God always have plan for us. Believe in the reason why we take this choice. Just do it. Good luck. :)