Wednesday, December 25, 2013

Selamat Natal 2013 / Merry Christmas 2013

Selamat natal 2013 bagi semua yang merayakannya. Semoga damai dan sukacita Natal selalu menyertai kita bukan hanya pada saat seperti ini namun juga sepanjang tahun 2014 nanti. Saya sendiri sudah merayakan Natal di gereja tadi pagi, namun sama seperti tahun kemarin, saya merayakannya tanpa keluarga tercinta. Saya memutuskan untuk pulang di liburan tahun baru saja. Bagaimanapun sekarang saya masih harus ke kantor. Berusaha membagi waktu antara kehidupan dan pekerjaan. Lebih baik segera saya selesaikan pekerjaan ini dan nanti malam bisa merayakan Natal bersama teman-teman. Selamat Natal & selamat liburan. :)


Merry Christmas 2013 for all of you who celebrate. I hope peace and joy of Christmas always be with us, not just at the moment, but also in the next 2014. I've celebrate Christmas this morning at the Church, but still the same as last year, I did it without my lovely family. I decide to go home in the new year holiday. Anyway, I'm still working and trying my best to manage time between life and work. And now, lets finish this job, so tonight I can celebrate Christmas with my friends. Merry Christmas & Happy holiday. :)

Thursday, December 19, 2013

Work HARD, Work SMART, TEAM Work

The title of this post may be very popular in some or even all circles. I think this title is a principle. For some people, I think they do not like hard work and prefer smart work and team work. Some people may choose different things. I think nothing is wrong or right.

If I am required to make the working sequence, then the result is thus:


Smart Work > Team Work > Hard Work

Why do I put such sequence?
  • We have to be smart in facing everything, whether life and work.
  • We have to be smart in choosing what is right and what is not.
  • We have to be smart in deciding which are profitable and what is not.
  • We have to be smart in doing what is meaningful and what is not.
I have a principle that everything that I could do by myself, I have to do it by myself and do not trouble others. If I do not work smart, I would end up burdening others. Before we co-operate, we must intelligently choose the person who will be our input in the team. We also have to be smart to identify the skills and personality of the person.

My job environment requires me to work closely with various parties, both internal company and external company. To achieve a result, required cooperation between the parties involved. As good TL / Team Leader, I am also require to maintain the harmony and stability of the team. Support and cooperation of all members is absolutely needed to the achieve an expected results.

When we are in a team, then the sequence may be changed to:

Team Work > Smart Work > Hard Work

Why? Because the result will be seen as a team achievement, not the individually. Each person will have a role that support that achievement. That role is require smart work. I am absolutely sure there is nobody who is an expert in all areas. God gives each person a unique talents. And finally, as part of a team, we demanded responsibility to provide the best for our team.

Finally, hard work is avoided by some people. If you can work smart and do team work, why hard work? Sometimes I also choose such principle. But circumstances could make it to be different. We are required to do more than smart, more than teamwork, that is hard work. For me, hard work must be done if we want something more, excellence. To achieve the desired results, it will require sacrifices, hard work is the answer.

This article is my personal writing that inspired from my experiences. I would like to ask for your forgiveness if there are any wrong words or less pleasing. Hopefully it is useful. Thank you. 

#Indonesian Translation

Monday, December 16, 2013

Kerja KERAS, Kerja CERDAS, Kerja SAMA

Judul postingan ini mungkin sangat populer di beberapa atau bahkan semua kalangan. Judul ini menurut saya adalah sebuah prinsip. Bagi sebagian orang, saya rasa tidak menyukai kerja keras dan lebih memilih kerja cerdas dan kerja sama. Sebagian orang lagi mungkin memilih hal yang berbeda. Saya rasa tidak ada yang salah maupun yang benar. 

Apabila saya diharuskan untuk membuat urutan kerja tersebut, maka hasilnya adalah demikian :

Kerja Cerdas > Kerja Sama > Kerja Keras

Mengapa saya menempatkan urutan-nya demikian?
  • Kita harus cerdas dalam menghadapi segala sesuatu baik itu kehidupan maupun pekerjaan. 
  • Kita harus cerdas dalam memilih apa yang benar dan apa yang tidak. 
  • Kita harus dalam cerdas menentukan mana yang menguntungkan dan apa yang tidak. 
  • Kita harus cerdas dalam melakukan apa yang bermakna dan apa yang tidak. 
Saya sendiri berprinsip bahwa segala sesuatu yang saya bisa kerjakan sendiri, saya harus lakukan sendiri dan jangan menyusahkan orang lain. Kalau saya tidak cerdas melakukan pekerjaan saya sendiri, akhirnya saya akan membebani orang lain. Sebelum kita bekerjsama, kita harus cerdas memilih orang yang akan akan kita masukan dalam tim. Kita juga harus cerdas mengidentifikasi keahlian dan kepribadian orang tersebut.

Lingkungan pekerjaan saya sekarang menuntut saya untuk bekerja sama dengan berbagai pihak, baik itu internal perusahaan maupun eksternal yaitu klien. Untuk mencapai sebuah hasil diperlukan kerjasama antara pihak - pihak yang terlibat.  Sebagai TL / Team Leader yang baik, saya juga diharuskan untuk menjaga harmoni dan stabilitas tim. Dukungan dan kerjasama dari semua anggota adalah mutlak demi tercapainya hasil yang diharapkan. 

Ketika kita berada dalam suatu tim, maka urutan-nya dapat berganti menjadi : 

Kerja Sama > Kerja Cerdas > Kerja Keras

Kenapa? Karena pencapaian yang dilihat adalah hasil akhir bersama, bukanlah individual.  Masing - masing orang akan memiliki peran yang mendukung pencapaian tersebut. Peran itulah yang membutuhkan kerja cerdas. Saya yakin tidak ada seseorang yang ahli di semua bidang pekerjaan. Tuhan memberikan manusia masing - masing talenta yang unik. Dan akhirnya, sebagai bagian dari tim, kita dituntut tanggung jawab untuk memberikan yang terbaik bagi tim kita.


Terakhir, kerja keras mungkin dihindari bagi sebagian kalangan. Kalau bisa kerja cerdas dan kerjasama kenapa harus kerja keras? Saya juga terkadang menganut prinsip demikian. Tapi keadaan bisa membuat itu menjadi berbeda. Kita dituntut untuk melakukan lebih dari cerdas, lebih dari sama, yakni keras. Bagi saya, kerja keras harus dilakukan apabila kita menginginkan sesuatu yang lebih, lebih dari sekedar baik yakni istimewa. Untuk mencapai hasil yang diharapkan diperlukan pengorbanan, kerja keras adalah jawabannya. 

Artikel ini adalah tulisan pribadi yang saya ilhami dari pengalaman saya. Mohon maaf apabila ada kalimat yang salah atau kurang berkenan. Semoga bermanfaat. Terima kasih. 

#Terjemahan Inggris

Sunday, December 15, 2013

Database Design Basic From Microsoft

I just want to remind my basic knowledge about database design. I live and work in custom solution environment. In order to deliver a good solution to my client, I think it is good to relearn again what I've been studied before. Now, to make sure everything is right, I summarize an article taken from Microsoft.

Database Design Basics

A properly designed database provides you with access to up-to-date, accurate information. Because a correct design is essential to achieving your goals in working with a database, investing the time required to learn the principles of good design makes sense. In the end, you are much more likely to end up with a database that meets your needs and can easily accommodate change.

In a simple database, you might have only one table. For most databases you will need more than one. Each row is also called a record, and each column, is also called a field. 
  • A record is a meaningful and consistent way to combine information about something.
  • A field is a single item of information — an item type that appears in every record.

#What is good database design?

Certain principles guide the database design process. 
  1. The first principle is that duplicate information (also called redundant data) is bad, because it wastes space and increases the likelihood of errors and inconsistencies. 
  2. The second principle is that the correctness and completeness of information is important. If your database contains incorrect information, any reports that pull information from the database will also contain incorrect information. As a result, any decisions you make that are based on those reports will then be misinformed.
A good database design is, therefore, one that:
  • Divides your information into subject-based tables to reduce redundant data.
  • Provides Access with the information it requires to join the information in the tables together as needed.
  • Helps support and ensure the accuracy and integrity of your information.
  • Accommodates your data processing and reporting needs.

#The design process

The design process consists of the following steps:

Determining the purpose of your database

It is a good idea to write down the purpose of the database on paper — its purpose, how you expect to use it, and who will use it. The idea is to have a well developed mission statement that can be referred to throughout the design process. Having such a statement helps you focus on your goals when you make decisions.

Finding and organizing the required information

To find and organize the information required, start with your existing information and forms. If you don't have any existing forms, imagine instead that you have to design a form to record the  information. What information would you put on the form? What fill-in boxes would you create? Identify and list each of these items.

As you prepare this list, don’t worry about getting it perfect at first. Instead, list each item that comes to mind. If someone else will be using the database, ask for their ideas, too. You can fine-tune the list later.

Next, consider the types of reports or mailings you might want to produce from the database. Design the report in your mind, and imagine what it would look like. What information would you place on the report? List each item. Do the same for the form letter and for any other report you anticipate creating.

Giving thought to the reports and mailings you might want to create helps you identify items you will need in your database.A key point to remember is that you should break each piece of information into its smallest useful parts. In general, if you want to sort, search, calculate, or report based on an item of information, you should put that item in its own field.

Dividing the information into tables

To divide the information into tables, choose the major entities, or subjects. When you design your database, always try to record each fact just once. If you find yourself repeating the same information in more than one place, place that information in a separate table. Once you have chosen the subject that is represented by a table, columns in that table should store facts only about the subject. 

Turning information items into columns

To determine the columns in a table, decide what information you need to track about the subject recorded in the table. Once you have determined the initial set of columns for each table, you can further refine the columns. If you want to perform a search, filter or sort operation by a column, you need the information stored in a separate column.

The following list shows a few tips for determining your columns. 
  1. Don’t include calculated data. In most cases, you should not store the result of calculations in tables. Instead, you can have the Applications perform the calculations when you want to see the result.
  2. Store information in its smallest logical parts. You may be tempted to have a single field for full names, or for product names along with product descriptions. If you combine more than one kind of information in a field, it is difficult to retrieve individual facts later. Try to break down information into logical parts; for example, create separate fields for first and last name, or for product name, category, and description.

Specifying primary keys

Each table should include a column or set of columns that uniquely identifies each row stored in the table. This is often a unique identification number, such as an employee ID number or a serial number. In database terminology, this information is called the primary key of the table. A primary key must always have a value. If a column's value can become unassigned or unknown (a missing value) at some point, it can't be used as a component in a primary key.

You should always choose a primary key whose value will not change. In a database that uses more than one table, a table’s primary key can be used as a reference in other tables. If the primary key changes, the change must also be applied everywhere the key is referenced. Using a primary key that will not change reduces the chance that the primary key might become out of sync with other tables that reference it.

Often, an arbitrary unique number is used as the primary key. For example, you might assign each order a unique order number. The order number's only purpose is to identify an order. Once assigned, it never changes.

If you don’t have in mind a column or set of columns that might make a good primary key, consider using a column that has the AutoNumber data type. When you use the AutoNumber data type, System automatically assigns a value for you. Such an identifier is factless; it contains no factual information describing the row that it represents. Factless identifiers are ideal for use as a primary key because they do not change. 

Now that you have divided your information into tables, you need a way to bring the information together again in meaningful ways. In a relational database, you divide your information into separate, subject-based tables. You then use table relationships to bring the information together as needed.
  • Creating a one-to-many relationship
To represent a one-to-many relationship in your database design, take the primary key on the "one" side of the relationship and add it as an additional column or columns to the table on the "many" side of the relationship.
  • Creating a many-to-many relationship
Note that to detect many-to-many relationships between your tables, it is important that you consider both sides of the relationship.

The answer of many-to-many relationship is to create a third table, often called a junction table, that breaks down the many-to-many relationship into two one-to-many relationships. You insert the primary key from each of the two tables into the third table. As a result, the third table records each occurrence or instance of the relationship.
  • Creating a one-to-one relationship
When you detect the need for a one-to-one relationship in your database, consider whether you can put the information from the two tables together in one table. If you don’t want to do that for some reason, perhaps because it would result in a lot of empty space, the following list shows how you would represent the relationship in your design:
  1. If the two tables have the same subject, you can probably set up the relationship by using the same primary key in both tables.
  2. If the two tables have different subjects with different primary keys, choose one of the tables (either one) and insert its primary key in the other table as a foreign key.

Determining the relationships between tables helps you ensure that you have the right tables and columns. When a one-to-one or one-to-many relationship exists, the tables involved need to share a common column or columns. When a many-to-many relationship exists, a third table is needed to represent the relationship. 

#Refining the design

Once you have the tables, fields, and relationships you need, you should create and populate your tables with sample data and try working with the information: creating queries, adding new records, and so on. Doing this helps highlight potential problems — for example, you might need to add a column that you forgot to insert during your design phase, or you may have a table that you should split into two tables to remove duplication.

See if you can use the database to get the answers you want. Create rough drafts of your forms and reports and see if they show the data you expect. Look for unnecessary duplication of data and, when you find any, alter your design to eliminate it.

As you try out your initial database, you will probably discover room for improvement. Here are a few things to check for:
  • Did you forget any columns? If so, does the information belong in the existing tables? If it is information about something else, you may need to create another table. Create a column for every information item you need to track. If the information can’t be calculated from other columns, it is likely that you will need a new column for it. 
  • Are any columns unnecessary because they can be calculated from existing fields? If an information item can be calculated from other existing columns — a discounted price calculated from the retail price, for example — it is usually better to do just that, and avoid creating new column. 
  • Are you repeatedly entering duplicate information in one of your tables? If so, you probably need to divide the table into two tables that have a one-to-many relationship.
  • Do you have tables with many fields, a limited number of records, and many empty fields in individual records? If so, think about redesigning the table so it has fewer fields and more records.
  • Has each information item been broken into its smallest useful parts? If you need to report, sort, search, or calculate on an item of information, put that item in its own column.
  • Does each column contain a fact about the table's subject? If a column does not contain information about the table's subject, it belongs in a different table.
  • Are all relationships between tables represented, either by common fields or by a third table? One-to-one and one-to- many relationships require common columns. Many-to-many relationships require a third table.

#Applying the normalization rules

You can apply the data normalization rules (sometimes just called normalization rules) as the next step in your design. You use these rules to see if your tables are structured correctly. The process of applying the rules to your database design is called normalizing the database, or just normalization.

Normalization is most useful after you have represented all of the information items and have arrived at a preliminary design. The idea is to help you ensure that you have divided your information items into the appropriate tables. What normalization cannot do is ensure that you have all the correct data items to begin with.

You apply the rules in succession, at each step ensuring that your design arrives at one of what is known as the "normal forms." Five normal forms are widely accepted — the first normal form through the fifth normal form. This article expands on the first three, because they are all that is required for the majority of database designs. 

1) First normal form

First normal form states that at every row and column intersection in the table there, exists a single value, and never a list of values. For example, you cannot have a field named Price in which you place more than one Price. If you think of each intersection of rows and columns as a cell, each cell can hold only one value.

2) Second normal form

Second normal form requires that each non-key column be fully dependent on the entire primary key, not on just part of the key. This rule applies when you have a primary key that consists of more than one column. For example, suppose you have a table containing the following columns, where Order ID and Product ID form the primary key:

    Order ID (primary key)
    Product ID (primary key)
    Product Name

This design violates second normal form, because Product Name is dependent on Product ID, but not on Order ID, so it is not dependent on the entire primary key. You must remove Product Name from the table. It belongs in a different table (Products).

3) Third normal form

Third normal form requires that not only every non-key column be dependent on the entire primary key, but that non-key columns be independent of each other.

Another way of saying this is that each non-key column must be dependent on the primary key and nothing but the primary key. For example, suppose you have a table containing the following columns:

    ProductID (primary key)
    Name
    SRP
    Discount

Assume that Discount depends on the suggested retail price (SRP). This table violates third normal form because a non-key column, Discount, depends on another non-key column, SRP. Column independence means that you should be able to change any non-key column without affecting any other column. If you change a value in the SRP field, the Discount would change accordingly, thus violating that rule. In this case Discount should be moved to another table that is keyed on SRP.

...

Original Source : Microsoft
Please note that the article in this blog contain some modification.

...

I like this Microsoft's article especially about the design process and refining the the design. Usually we do it randomly, so we get confused in the end and forced to refine all over again. Now, from this article we have learned what we gonna do and the most important thing what we should do. Please click here to find out about database types and how to make a relational database. I have posted about ERD (Indonesian Translation Only), and database design best practices.Thank you.

Monday, December 9, 2013

Terms Of BI / Busienss Intelligence Implementation - BI Adventure

Greetings. Still on the theme of BI Adventure, previously i discussed about BI FAQ, this time I would like to discuss about something different but still related. Today's discussion is about 1 of the existing FAQ. It is about main requirements of BI implementation.

As I have written briefly, the main requirements of BI are solid and integrated database. Why they are important? Because BI require data as capital, not file or information.

What is file / archive?
File is a set of related record. File also mean archive in Indonesian.

According to KBBI =
  1. Written documents (letter, certificate, etc), verbal or pictorial (photo, film, etc) from past times, saved in written media (paper), electronic (cassette tape, video tape, cd, etc), usually issued by formal institution or agency, stored, and maintained in a special place for reference.
  2. Standardization, regulation, and preservation of archival material that is needed in order to be recognized and organized as the original without anyone who tampered with and altered.
According to Oxford Dictionaries =
  1. A folder or box for holding loose papers together and in order for easy reference.
  2. A collection of information about a particular person or thing.
  3. Computing a collection of data, programs, etc. stored in a computer’s memory or on a storage device under a single identifying name.

Conclusion : file / archive is a "place" that used for "save" collection of "data or information" about something for documentation or "reference".

What is data? What is information?
  • Data = Is a fact that its shape can be text, sound, images, numbers, symbols, and so on, or the information is kept back as a fact that which has not had a clear meaning.
  • Information =  Is data that has been processed and has meaning that can be used for a specific purpose or decision making.
  • What report and dashboard will you make?
  • What will be your analysis?
Next question, if there is no database :
  • How to process data into information without database?
Last, if there is no solid and integrated database :
  • How do you ensure the validity of the data?
All 4 questions above are compulsory question that I always ask earlier to my client and user. Based on that experience, i classify client / user level according to their answers. Here they are :

Okay, you've got the data, now : Where do you keep your data? Archive or written? Or system? Or data warehouse?

Level 1 - Basic
 
Oh, keep calm... We store most of our company data in 'excel system', but some of them written or hardcopy.

A very classic answer that always we heard of and created another serial question :
What is excel system? Is excel a system? How big it's size? Some of them is subjective, how many?

In my perspective, microsoft excel is not a system or database. It is a product that created by Microsoft to help people process their data mathematically.

The collection of excel files can be tens, hundreds even thousands of files. It could also be in units of Byte, KB, MB, GB or even TB, etc. My experience when dealing with hardcopy or printed data, the number is not too much : can be dozens to tens for master data such as suppliers or customers, but these things can more difficult when it has several versions that we don't know whichever most valid version. It is called messy, while in IT language : not integrated. Hahaha...

So excel is better? Haha.. Who said that?

Imagine an excel file larger than 100MB. It is a torture for a less qualified notebook to open that file. If you can open it, certainly it takes time and you must close any other open programs. Hehe

Okay, back to our main topic : "data". Both excel and hardcopy, all contain data. One thing that I can assure you, that 9 of the 10 data in Excel are not integrated. The simple one is about naming : branch name, product name and business district code. All these things hard to be limited, especially it has no systems or manual processes.

Unintegrated data in excel file spawn another problem : how to unite all as one entity? Example : English Book or Eng Book. Which one is correct? We all can consider them as a single entity : a book, but system will consider it as 2 book. It was about master data. Can you imagine the transactions? Hahaha

If you still have all of these problem, it is wise if you do not implement BI before you optimize and create systems to support your business Application. SAP, Oracle, Microsoft Dyanmics or even Custom.NET are solutions that you can choose according to the budget you have.

Level 2 - Bloom
We have SAP for finance, AS400 for production and Acces for sales.

Well, looks better? Fine, we can skip several questions from level 1 and focus on the end : "Integration". Having many systems may not be an advantage if it is not integrated. Case : In SAP. product code use numeric (1, 2, 3) while in AS400 using letters (a, b, c) If 1=a, 2=b, 3=c, then it may be a great help, but is it always correct? In my past projects, everything was never the same and come in pairs. Hahaha.

For case like this, it needs extra effort to mapping or matching all master data in all running systems. How long? The answer is uncertain. Usually, each system is owned and used by multiple divisions. In this case, if it take 1 person per 1 system, we must hope that they understand all of the data. Another problems, rarely a person understand all at once, even though the System Support.

This kind of system is like a developing country, still needs a lot of repairs done internally. If the case like this, both users and consultants must cooperate to solve this problem, then proceed with the BI development. Once again without a strong and integrated data, the BI foundation will be weak and complicated, which eventually might become a waste.

Level 3 - Advance
 
There are several systems owned by our company : SAP, Custom .NET Applications and Access. For the current reporting we use  SAP as a reference for master data and transactions.

It appears that the BI project will not be too difficult. It is obvious that the the existing references is already clear. BI foundation already exists, so we can directly move to the next phase : to evaluate and test the feasibility for the creation of  a data warehouse. Do not forget to check back the data that also needed by the dashboard and reports later.

A few things to note is the level of integration. Integrated might be not complete, complete might be not integrated. Usually target or plan data have not been inserted into the system or database. Certainly, the business users will see their KPI achievement against their targets. Therefore it is required to make a simple application to store and stream the data into the data warehouse. At least, in this level, you will have a good start. Hehe...

Level 4 - Modern

Sir... For current reporting, we have a data warehouse retrieved from ERP System. The only matters, we feel that our reporting and analysis not really accurate, efficient and maximum.

I will be more happy when the client answer me with a sentence that has similar meaning with above sentence. Hahaha. The conclusion that can be generated from the user answer is : capital and container (database) are no longer an obstacle to the BI implementation and certainly clients need solutions to enable the business users to analyze and generate reports more accurate, fast and attractive. Please take a note that the existing data warehouse still needs to be evaluated. In addition to the BI product it self, the DW design and structure determine the performance and the speed of processing / query data.

Up to this time, I rarely find such a client. There is also a case that they already have other BI products, but the clients want a more powerful tools. Product benchmarking is needed to ensure that the solutions will be delivered by consultants align with the clients specification and requirements. Do not ever offer something that cannot meet the expectations or even worse from anything that has existed at this time.

...

In the end, I would just repeat that the foundation of Business Intelligence is a powerful and integrated database. They are absolutely something must be achieved before implementing BI product. Strong and integrated data will make the result more varied, attractive and inspiring, not just gossips that it's validity questionable. In addition, for the level no4 case, knowledge of BI product will be an unavoidable necessity. Last, I always say this everytime I post on this blog : All stories is based on my opinions and personal experiences. If there are shortcoming and mistakes, please forgive me and  I welcome you to provide any feedback on any post. Thank you.

Wednesday, December 4, 2013

Syarat Implementasi BI / Business Intelligence - Seri Petualangan

Salam sejahtera semuanya. Masih dalam tema petualangan BI, bila sebelumnya saya membahas BI FAQ, kali ini saya akan membahas sesuatu yang lain namun masih berkaitan. Pembahasan kali ini adalah salah satu FAQ yang ada, yakni syarat dan fondasi utama implementasi BI.

Seperti yang telah saya tulis secara singkat, syarat utama BI adalah basis data yang kuat dan terintegrasi. Mengapa hal ini penting? Penjelasannya adalah karena BI membutuhkan data sebagai modal. Sekali lagi data bukan file atau informasi. 

Apa itu file / arsip? 
File adalah kumpulan record / catatan yang saling berhubungan. File juga berarti arsip dalam bahasa Indonesia.

Menurut KBBI =
  1. Dokumen tertulis (surat, akta, dsb), lisan (pidato, ceramah, dsb), atau bergambar (foto, film, dsb) dari waktu yg lampau, disimpan dimedia tulis (kertas), elektronik (pita kaset, pita video, disket komputer, dsb), biasanya dikeluarkan oleh instansi resmi, disimpan dan dipelihara di tempat khusus untuk referensi.
  2. Pembakuan, pengaturan, dan pengawetan yg diperlukan supaya bahan arsip dapat dikenal dan disusun sebagaimana aslinya tanpa ada yg dirusak dan diubah.
Menurut Oxford Dictionaries =
  1. A folder or box for holding loose papers together and in order for easy reference.
  2. A collection of information about a particular person or thing.
  3. Computing a collection of data, programs, etc. stored in a computer’s memory or on a storage device under a single identifying name.
Kesimpulannnya, file / arsip adalah "tempat" yang digunakan untuk "menyimpan" kumpulan "data ataupun informasi" tentang sesuatu yang bertujuan untuk dokumentasi dan "referensi".

Apa itu data? Apa itu informasi?
  • Data = Adalah suatu fakta yang bentuknya bisa tulisan, suara, gambar, angka, simbol, dan sebagainya,  ataupun informasi yang disimpan kembali sebagai suatu fakta yang mana belum memiliki arti yang jelas.
  • Informasi = Adalah data yang telah diproses dan telah memiliki arti yang dapat digunakan untuk tujuan tertentu ataupun pengambilan keputusan.

Silahkan klik disini untuk penjelasan lebih lanjut.  

Selanjutnya, apabila tidak ada data : 
  • Apa yang mau dibuat laporan dan dashboardnya?  
  • Apa yang mau dianalisa?  
Pertanyaan selanjutnya, apabila tidak ada basis data : 
  • Bagaimana mengolah data menjadi informasi tanpa basis data?
Terakhir, apabila basis datanya tidak kuat dan tidak terintegrasi :
  • Bagaimana anda memastikan validitas data tersebut?

Empat pertanyaan diatas adalah pertanyaan wajib yang saya selalu tanyakan diawal kepada klien atau user. Berdasarkan pengalaman itulah saya mengklasifikasikan level klien / user melalui jawaban beberapa pertanyaan berikut ini :

Ok lah, anda memiliki data, sekarang : Dimana data anda disimpan? Arsip fotocopy dan tertulis? Ataukah sistem? Ataukah Data Warehouse (Gudang Data)?

Level 1 - Dasar 
Oh, tenang kami menyimpan data perusahaan sebagian besar di 'sistem excel' koq, namun ada juga sedikit yang masih berupa tertulis / hardcopy.

Sebuah jawaban klasik, yang mungkin sering kita dengar dan memunculkan kembali pertanyaan lainnya:

Apa itu 'sistem excel'? Apakah excel adalah sistem? Berapa ukuran excelnya?
Sedikit itu subjektif, berapa banyak?

Menurut saya microsoft excel bukanlah sebuah sistem ataupun basis data, namun adalah sebuah produk. Produk yang diciptakan oleh Microsoft guna membantu orang untuk mengolahkan data yang sifatnya matematis.

Sedikit menurut tiap orang berbeda, bisa puluhan, ratusan, bahkan bisa ribuan file. Bisa juga dalam satuan Byte, KB, MB, GB atau bahkan TB, dsb. Pengalaman saya ketika berhubungan dengan data hardcopy / tercetak, jumlahnya gak terlalu banyak : bisa belasan sampai puluhan saja untuk master data seperti supplier atau customer, namun yang lebih sulit semuanya itu bisa saja memiliki beberapa versi yang entah mana versi paling valid, bahasa kasarnya adalah berantakan, sedangkan bahasa IT-nya sih tidak terintegrasi. Hahaha.

Berarti yang excel lebih baik donk? Hahaha. Siapa bilang?

Coba bayangkan sebuah file excel berukuran lebih dari 100MB. Sebuah penyiksaan terhadap laptop yang kurang mumpuni untuk membuka file tersebut. Kalau bisa dibukapun tentu butuh waktu dan anda diharuskan menutup program lain yang anda buka. Hehehe.

Oke, kembali ke topik utama : "data". Baik excel maupun hardcopy semuanya mengandung data. Satu hal yang saya berani jamin, bahwa 9 dari 10 data di excel itu tidak terintegrasi. Contohnya adalah penamaan : penamaan cabang perusahaan, penamaan produk, pengkodean wilayah bisnis. Semuanya itu jarang bisa dibatasi khususnya yang bukan berupa sistem dan manual proses seperti excel.

Tidak terintegrasinya data dalam file excel tersebut kembali melahirkan masalah lain, yakni bagaimana menyatukan semuanya sebagai satu kesatuan? Contoh : Buku Bahasa Indonesia dengan Buku Bhs Indonesia. Secara manusia, itu bisa dianggap sebagai satu kesatuan, namun dalam sistem itu dianggap sebagai 2 buku. Itu baru master data, bagaimana dengan transaksinya? Bisakah anda bayangkan? Hahaha.

Bila anda masih memiliki masalah tersebut, sangat bijaksana sekali apabila anda tidak mengimplementasikan BI sebelum anda mengoptimalkan dan membuat sistem aplikasi untuk mendukung bisnis anda. SAP, Oracle, Microsoft Dynamic, atau bahkan Custom .NET adalah solusi yang anda bisa pilih sesuai dengan budget yang anda miliki.

Level 2 - Berkembang
 
Kami memiliki SAP untuk Finance, AS400 untuk produksi, Access untuk penjualan.

Wah nampaknya yang level ini sudah lebih baik? Ok lah, kita bisa mengskip beberapa pertanyaan seperti dalam level 1, dan fokus pada akhirnya : "Integrasi". Memiliki banyak sistem belum tentu menjadi sebuah keunggulan apabila tidak terintegrasi. Bayangan kasus berikut ini : Di SAP kode produk menggunakan numeric (1, 2, 3, ...) sedangkan di AS400 menggunakan huruf (a, b, c, ...). Jika 1 adalah a, 2 adalah b, maka mungkin bisa banyak membantu, tapi apakah demikian? Belum tentu, dan seumur hidup saya dalam proyek, semuanya tidak pernah sama dan sepasang. Hahaha.

Untuk kasus begini, diperlukan kerja keras extra untuk me-mapping-kan atau menjodohkan semua master data yang ada di semua sistem berjalan. Berapa lama? Jawaban yang tidak pasti. Biasanya setiap sistem dimiliki dan dipakai oleh beberapa divisi. Dengan kasus disini dibutuhkan 1 orang @sistem, itupun kalau mereka mengerti semua data. Masalah baru deh, jarang sekali ada orang yang mengerti semua sekaligus, bahkan System Support sekalipun.

Sistem seperti ini ibarat negara berkembang, masih perlu banyak perbaikan internal yang dilakukan. Apabila kasusnya begini, baik user maupun konsultan wajib bekerjasama untuk menyelesaikan masalah ini, baru kemudian melanjutkan pengembangan BI. Sekali lagi tanpa data yang kuat dan terintegrasi, fondasi BI akan menjadi lemah dan rumit, yang akhirnya mungkin hanya akan menjadi sampah.

Level 3 - Maju
 
Ada beberapa sistem yang perusahaan kami miliki, SAP, Custom .NET Application, dan Access. Untuk reporting saat ini kami menggunakan acuan master data  dan transaksi yang berasal dari SAP.

Nampaknya proyek BI ini tidak akan terlalu sulit. Sudah jelas sekali bahwa acuan yang digunakan sudah ada dan jelas. Fondasi untuk BI sudah ada, sehingga kami dari pihak konsultan bisa langsung ke tahap evaluasi dan uji kelayakan untuk pembuatan gudang data / data warehouse. Jangan lupa mengecek kembali juga data-data yang dibutuhkan untuk dashboard dan reportnya nanti.

Beberapa hal yang perlu diperhatikan adalah level integrasinya. Terintegrasi belum tentu lengkap, dan lengkap belum tentu terintegrasi. Maksud dari integrasi disini adalah biasanya data plan / target belum dimasukan ke dalam sistem atau database. Sudah pasti bahwa hal yang pertama kali dilihat oleh business user adalah pencapaian KPI terhadap target-nya. Apabila demikian diperlukan pembuatan aplikasi sederhana untuk menyimpan dan mengalirkan data tersebut kedalam gudang data. Setidaknya, apabila dalam level ini, anda akan memiliki start yang baik. Hehe.

Level 4 - Modern 
Pak.. Untuk keperluan reporting saat ini, kami memiliki gudang data atau Data Warehouse yang sumber datanya diambil dari DB dari ERP System yang kami miliki. Hanya saja kami rasa reporting dan analisa saat ini kurang akurat, efisien dan maksimal.

Saya akan sangat terharu sekali jika ketika pihak client ada yang menjawab kurang lebih bermakna sama dengan kalimat dari saya diatas. Hahaha. Kesimpulan yang bisa dihasilkan dari jawaban user seperti itu adalah : modal data dan tempatnya (basis data) sudah bukan lagi menjadi halangan untuk implementasi dan pastinya klien membutuhkan solusi untuk membantu mereka dan tentunya business user untuk menganalisa dan menghasilkan report yang lebih akurat, cepat dan atraktif. Perlu menjadi catatan bahwa gudang data /DW yang telah ada / dimiliki klien tersebut tetap perlu dievaluasi. Selain product BI itu sendiri, desain serta struktur DW menentukan performa dan kecepatan dari proses memasak / query data.

Sampai dengan saat ini saya jarang menemukan client yang demikian. Ada juga kasusnya mereka telah memiliki product BI lainnya namun klien menginginkan tools / product yang lebih hebat daripada yang telah mereka miliki. Benchmarking product sangatlah diperlukan untuk memastikan solusi yang dibawakan oleh konsultan apakah sesuai dengan spesifikasi dan kebutuhan dari klien tersebut atau tidak. Jangan sampai dari pihak konsultan menawarkan sesuatu yang tidak dapat memenuhi ekspetasi atau malah lebih jelek daripada sesuatu yang telah ada saat ini.

... 

Akhir kata, saya hanya akan mengulang bahwa fondasi dari Business Intelligence adalah basis data yang kuat dan terintegrasi. Ini adalah sesuatu yang sifatnya mutlak dan harus dimiliki sebelum mengimplementasikan product BI. Kuat dan integrasinya data akan membuat informasi yang dihasilkan semakin variatif, atraktif dan inspiratif, bukan sekedar gossip yang diragukan validitasnya. Selain itu, untuk kasus level no4, pengetahuan akan product BI akan menjadi suatu kebutuhan yang tidak dapat dihindarkan. Terakhir, selalu saya sampaikan bahwa semua yang saya tulis dalam blog ini sifatnya adalah pendapat, berlandaskan pengalaman pribadi. Apabila ada kekurangan dan kesalahan, saya meminta maaf dengan setulus - tulusnya dan dipersilahkan memberikan feedback atas setiap tulisan yang saya buat. Terima kasih.

Monday, December 2, 2013

Selamat Datang Desember, Selamat Tinggal November

Akhirnya Desember datang juga. Selamat datang Desember, selamat tinggal November. Waktu berlalu sangat cepat, mungkin terlalu cepat untuk saya. Pertama-tama marilah kita bersyukur kepada Tuhan Yang Maha Kuasa karena Ia telah mengijinkan kita melaluinya. Malam ini saya ingin berbagi quote favorit saya lainnya :

“Jangan menangis karena itu berakhir, tersenyumlah karena itu terjadi.”
-- Oleh Dr. Seuss

November lalu adalah salah satu bulan terberat di 2013. Banyak tantangan dan peluang saya lewatkan, banyak jadwal yang berantakan, hidup sangat tidak mudah untuk saya. Menangis dan kesedihan tidak akan membuat hal-hal menjadi lebih baik ataupun berubah. Setelahnya, waktu berlalu dan saya hanya bisa tersenyum dan mengambil pengalaman yang ada. Jangan menyerah, yakini bahwa sesuatu terjadi karena sebuah alasan. Tuhan berkati. :)

Sunday, December 1, 2013

Welcome December - Good Bye November

Finally December came. Welcome December, Good Bye November. Hmm, time running so fast, maybe too fast for me. First of all, lets us give thanks to the Lord, that He allow us through the time. Tonight, I would like to share another favorite quotation of mine :

“Don't cry because it's over, smile because it happened.”
-- By Dr. Seuss

Last November was one of toughest time in 2013. Many challenge and chance I miss, a lot of messy schedule, life was uneasy for me. Cry and sadness won't make the things better or change. After all, time passed and I can only smile and grab the experiences. Don't give up, believe that things happened for a reason. God bless you. :)