Awal th 92, setelah 2 th berusaha menabung 75% dari gaji bulanan (kok bisa? ya iya wong makan dan tidur masih nebeng orangtua) ditambah uang saku dari hasil ngerjain proyek di jepang selama 3 bulan akhirnya saya bisa bayar DP rumah di daerah Harapan Baru Taman Bunga Cibubur. Senang? Ya iya lah, namanya masih kuliah, baru kerja 2 th, sdh dapat rumah.
Memang dari awal saya bekerja, target awal adalah segera beli rumah sendiri, karena saya merasakan sendiri kesulitan yang saya alami karena berpindah-pindah tempat tinggal.
Lokasi rumah ini saya temukan tidak sengaja saat sedang jalan-jalan. Saya lihat lokasinya persis di pinggir jalan raya. Aksesnya relatif mudah. Dekat dengan tempat tinggal orangtua. Yang paling penting, nilai DPnya cocok dg kocek.
Akhirnya saya ambil satu rumah tipe 45/120.
DP saya bayar cicil selama beberapa bulan, kalo ga salah 6 bulan. Sambil mencicil DP, proses dibarengi dengan kegiatan usaha memperoleh KPR.
Dari menyiapkan surat keterangan dokter, surat keterangan kerja, surat keterangan penghasilan, pengisian form pengajuan KPR. Ini semua adalah hal baru buat saya saat itu. Yang saya rasakan adalah pengisiannya dokumennya cukup tricky... ;)
Akhirnya rumah sdh jadi, dan saya dipanggil untuk wawancara kredit, dan... berhasil. Walau sebetulnya ini cukup berat untuk saya. Saya ambil kredit 5 th. Dan besar cicilan bulanannya nyaris 70% gaji bulanan.
Tapi ga apa-apa, saya sdh biasa berhemat sejak kecil. Jaman SMA saya pernah rutin beli permen chicklet isi 12 biji seharga rp. 200. Tiap hari saya hanya bawa 2 biji untuk jatah 1 hari, soalnya kalo saya bawa sebungkusnya, bisa habis diminta teman-teman. Dengan cara seperti itu rp. 200 bisa buat seminggu, hehehe... Ini sih bukan hemat pangkal kaya, tapi memang karena uang jajan cekak.
Nyaris tiap sore sepulang kantor saya datangi rumah itu, saya tanami rumput, buat taman, saya pel, pokoknya saya ingin rumah itu kelihatan rapih setiap saat.
Sayangnya, akhirnya rumah ini tidak pernah saya tempati. Karena sejak menikah tahun 1995, saya menempati rumah yang lain, dan rumah ini kemudian disewakan sampai sekarang.
Sejak beberapa tahun yang lalu saya sempat dengar selentingan akan ada pembangunan jalan tol dari depok ke jagorawi, tapi lokasi mana yang tergusur tidak pernah jelas.
Sampai hari minggu lalu saya menerima pemberitahuan dari Pak RT Darmawan (beliau adalah boss saya dikantor yang lama yang dulu sama-sama ke jepang dan kemudian sama-sama beli rumah di lokasi yg sama, dan kemudian sama-sama tergusur) untuk hadir di rapat RT yang membahas soal penggusuran.
Akhirnya... setelah sekian lama terlalu sering membaca berita tentang penggusuran untuk berbagai macam proyek... eh... ternyata saya mengalami sendiri. Rumah yang sangat bersejarah akhirnya akan jadi jalan tol.
Memang belum jelas berapa nilai penggantiannya, tapi yang saya dengar, Pak Nur Mahmudi walikota depok menjanjikan ganti untung, bukan ganti rugi.
Harusnya memang begitu. Dengan adanya jalan tol cinere jagorawi (Cijago) ini, pemerintah diuntungkan, kontraktor untung, pengelola untung, warga pemakai untung, warga sekitar untung, masa cuma kita-kita pemilik tanah yg lokasinya dijadikan jalan tol yang tidak untung? Kan keterlaluan... tul ga? Kita lihat saja janji pak Walikota yang mantan petinggi partai PKS ini, mudah2an bisa memegang amanah.
Selain itu, kalo kita digusur, yah.. pengennya sih bisa untuk beli rumah lagi minimal dengan luas tanah dan bangunan yang sama di lokasi dekat2 situ, ditambah biaya pindah, ditambah biaya urus ini-itu, ditambah kompensasi benefit, rasanya ga terlalu berlebihan kan?
Sebetulnya saya ada terpikir opsi lain. Bagaimana kalau misalnya nilai bangunan kita dikonversi jadi saham di jalan tol tsb? Tapi untung ga ya buat kita2?
Dari hasil rapat kemarin diinformasikan uang gusuran akan dibayarkan sekitar bulan april 2007. Mudah2an semua lancar....
Ada teman yang tanya, duit gusuran mo buat apa?
Yang pasti ga buat kawin lagi...... hehehehe......
Sunday, December 10, 2006
Tuesday, December 5, 2006
Pensiun ngapain ya?
Mendekati or memasuki umur kepala 4, apa sih yang dilakukan dalam menghadapi masa pensiun? Apa cuma mengandalkan gaji or pesangon di hari tua? Perlukah membuka jalur bisnis baru?
Ngitung2 dikit ah...
Kita kerja berapa tahun lagi ya.. 55-37 = 18 th lagi.
Kebutuhan kita sebulan sekarang berapa? Misal 15 jt, tapi nanti di umur 55 kan anak udah pada cari kerja sendiri, trus kita jarang clubbing, paling di rumah miara ikan.. hehe.. jadi paling abis 5 jt an.
Kalo dg asumsi inflasi 10%/th, maka duit 5 juta (nilai sekarang) akan sama dg 28 jt (nilai 18 th lagi).
Pertanyaan, bagaimana supaya setelah pensiun kita bisa tetap terima minimal 28jt / bulan utk menjaga supaya kualitas hidup kita ga merosot?
Dari deposito gimana? Sekarang bunga deposito cuma 6% an, udah sedikit, eh masih dipotong pajak lagi. Jadi supaya bisa terima bunga 28 jt/bln, duit deposito kita harus ada minimal kira-kira 5,5 milyar.
Sekarang utk bisa punya deposito 5,5 M, mesti nabung berapa ya? Hitung2an saya sih kita jatuhnya mesti nabung 14 jt / bln selama 18 th dg bunga 6%.
Dg asumsi kita cuma bisa nabung 25% dari penghasilan, berarti penghasilan kita sekarang minimal harus 60jt /bln. Tapi balik muter lagi, kalo skrg penghasilan 60 jt / bln, apa sanggup 18 th lagi hidup cuma dg nilai sekarang 5 jt / bln? Bisa serasa miskin lagi... hehehe...
Intinya ga mungkin mengandalkan deposito atau tabungan, kecuali tiba2 kita terima dana hibah gede2an.
Investasi? Hmm... nanti lagi ah nulisnya, to be continued.
Ngitung2 dikit ah...
Kita kerja berapa tahun lagi ya.. 55-37 = 18 th lagi.
Kebutuhan kita sebulan sekarang berapa? Misal 15 jt, tapi nanti di umur 55 kan anak udah pada cari kerja sendiri, trus kita jarang clubbing, paling di rumah miara ikan.. hehe.. jadi paling abis 5 jt an.
Kalo dg asumsi inflasi 10%/th, maka duit 5 juta (nilai sekarang) akan sama dg 28 jt (nilai 18 th lagi).
Pertanyaan, bagaimana supaya setelah pensiun kita bisa tetap terima minimal 28jt / bulan utk menjaga supaya kualitas hidup kita ga merosot?
Dari deposito gimana? Sekarang bunga deposito cuma 6% an, udah sedikit, eh masih dipotong pajak lagi. Jadi supaya bisa terima bunga 28 jt/bln, duit deposito kita harus ada minimal kira-kira 5,5 milyar.
Sekarang utk bisa punya deposito 5,5 M, mesti nabung berapa ya? Hitung2an saya sih kita jatuhnya mesti nabung 14 jt / bln selama 18 th dg bunga 6%.
Dg asumsi kita cuma bisa nabung 25% dari penghasilan, berarti penghasilan kita sekarang minimal harus 60jt /bln. Tapi balik muter lagi, kalo skrg penghasilan 60 jt / bln, apa sanggup 18 th lagi hidup cuma dg nilai sekarang 5 jt / bln? Bisa serasa miskin lagi... hehehe...
Intinya ga mungkin mengandalkan deposito atau tabungan, kecuali tiba2 kita terima dana hibah gede2an.
Investasi? Hmm... nanti lagi ah nulisnya, to be continued.
Sunday, December 3, 2006
Copy - Paste
Paling enak kalo ngetik tinggal copy paste, ctrl+c, ctrl+v, jadi deh.
Teks, rumus, gambar, screenshot semua jadi dalam hitungan detik.
Nggak perlu repot dengan mengetik huruf demi huruf.
Kalo saja omzet bisa di copy paste dg mudah...
Buka satu counter, untung.. ctrl+c,
Cari lokasi baru... ctrl+v,
Cari lokasi lain lagi... ctrl+v lagi.
Kalo omzet 50 juta sebulan, copy paste 5 kali, udah 250 juta sebulan....
Bisa jadi kayak Cak Bukhin, karyawan beromset milyaran.
Bayanginnya enak ya... :)
Tapi prakteknya berat,
survey tempat baru,
ketemu beberapa lokasi bagus,
milihnya udah bingung, mana yg paling strategis,
begitu diputuskan lokasinya.. eh duit ga cukup,
nego, nego.... buntutnya cari utangan dulu,
sementara kredit ga bisa cair dalam waktu dekat,
hari libur kepake mondar mandir kesana kemari,
pegel udah pasti,
belum acara diserempet angkot....
Sulit tapi seru utk dinikmati.
[bersyukur masih bisa menikmati kesulitan]
Teks, rumus, gambar, screenshot semua jadi dalam hitungan detik.
Nggak perlu repot dengan mengetik huruf demi huruf.
Kalo saja omzet bisa di copy paste dg mudah...
Buka satu counter, untung.. ctrl+c,
Cari lokasi baru... ctrl+v,
Cari lokasi lain lagi... ctrl+v lagi.
Kalo omzet 50 juta sebulan, copy paste 5 kali, udah 250 juta sebulan....
Bisa jadi kayak Cak Bukhin, karyawan beromset milyaran.
Bayanginnya enak ya... :)
Tapi prakteknya berat,
survey tempat baru,
ketemu beberapa lokasi bagus,
milihnya udah bingung, mana yg paling strategis,
begitu diputuskan lokasinya.. eh duit ga cukup,
nego, nego.... buntutnya cari utangan dulu,
sementara kredit ga bisa cair dalam waktu dekat,
hari libur kepake mondar mandir kesana kemari,
pegel udah pasti,
belum acara diserempet angkot....
Sulit tapi seru utk dinikmati.
[bersyukur masih bisa menikmati kesulitan]
Tuesday, November 28, 2006
Cutting ERP implementation down to size
Source : The Manufacturer US
One size does not fit all when it comes to figuring out the costs, timing, and keys to success for an ERP implementation. Jill Rose reports.
There are a lot of nightmare ERP implementation stories out there. You’ve probably heard one or two. But for each of these stories, there is an equal amount of wisdom from people like Dan Bridgeman, director of business applications for ADC Telecommunications in Minneapolis.
Bridgeman, his team, and their colleagues have conducted more than 50 ERP deployments around the world since June 1997, thanks to a worldwide adoption of SAP and a spate of acquisitions by the $2.4 billion manufacturer of telecommunications equipment. Out of ADC’s experience has emerged a project plan that crystallizes the crucial components of successful ERP implementations among all sizes of manufacturing enterprises: a focus on business process; clear communications among project teams, executives, users, vendors, and consultants; and a healthy balance between discipline and flexibility.
Companies seeking to improve their ERP implementation processes tend to focus on money and time: what does it cost and how long will it take? The answer, inevitably, is the same: it depends. ADC will spend about $1 million on its current four-month SAP deployment at a recently acquired company with roughly 2,000 fairly dispersed users. A.W. Chesterton Company, a private manufacturer of industrial fluid sealing, hydraulic/pneumatic, and maintenance products, invested about $2 million during its 20-month, global implementation of an Intentia ERP system. Small companies can conduct a rapid implementation within two months for less than $100,000 through Exact Software North America, or they can opt for a $150,000 investment during a three- to six-month Exact Software implementation with far greater levels of customization and training. Again, it all depends.
“We can take two manufacturers based in Ohio, both making metal fasteners,” says William Wohl, a spokesperson for SAP America in Newtown Square, PA. “Suppose both companies need to create an enterprise system to do what most people think of when they think of ERP. Both companies will approach the project differently; both will wind up spending different amounts of money. Both projects will take different lengths of time to complete. And both could have very different outcomes.” That’s because the success of any ERP installation hinges on the redesign of business processes.
“The most important step you take is not the installation of software on a CD, but the mapping of basic business processes to best practices—or for some companies, the first real identification of what business processes are,” says Wohl.
If one of the world’s leading technology solutions companies emphasizes business process over technology, there must be something to it. And SAP is not alone. Syspro Group, one of the leading ERP providers to the manufacturing sector, first published its implementation methodology, STARS (Structured Technique to Achieve Rapid Solution), in 1998. Earlier this year, Syspro completely rewrote STARS. The new version is business process-based, whereas the first two versions of the methodology were “impact modular based” (i.e., focused on the ERP system’s groupings of financial, distribution, and manufacturing capabilities).
“We found that people weren’t thinking modularly,” says Syspro Vice President of Marketing Joey Benadretti. “They were thinking in terms of process flows. What’s a sales flow? What’s a purchasing flow? What’s the flow on the shop floor? That’s how a manufacturing company addresses it. We believe we have arrived at the point, from an implementation perspective, where we need to look at the business process phases rather than from the impact modular based perspective. Reengineering internal processes is a major step forward for companies that want to gain from the information technology. But there is no reason to implement a new system if you’re not going to take advantage of the technology and the new processes you can perform to save time and money.”
A.W. Chesterton, for example, assigned “process owners” roles as part of its implementation of Intentia’s Movex ERP system. “We had somebody in charge of finance across the company, somebody in charge of customer order maintenance across the company, and so on,” says Anne Wightman, information system operation manager for A.W. Chesterton in Stoneham, Ma. “The tricky part was that we had five different manufacturing divisions at the time. So, even though we had one person in charge of manufacturing as a process owner, they had to make sure that those five different divisions were represented well enough in their own unique areas so they could work with the way the system was being configured. Process owners operated at the highest level. If we had an issue in manufacturing, everybody knew that Paul was the person to go to, and he kept track of where we stood and tracked the issue log.”
Chesterton used Intentia’s Implex implementation methodology. Bridgeman notes that ADC’s methodology closely resembles SAP’s Solution Maps methodology. And Chris Holbert, director of IT for North American Scientific Inc., a manufacturer of radioactive medical devices in Chatsworth, Calif., says Exact Software was “very helpful in providing an overview of its ERP functionality and what is possible through the software.” These and other examples signify the trust that companies bestow on their vendors in successful implementations.
Part and parcel with that trust, however, is the recognition that consulting services, from vendors or their implementation partners, can make up a hefty chunk of the final bill. The successful ERP implementations at A.W. Chesterton and ADC Telecommunications included careful monitoring of consulting hours.
Responsible vendors and consultants respond to this need by transferring their knowledge as efficiently as possible. Early on in ADC’s ERP implementation activity, systems integration and IT consulting firm CSC, along with SAP consultants, were much more involved in the process. “As we gathered that knowledge, we weaned ourselves because that work can get very expensive,” says Bridgeman. “We still gain significant value from calling on them, but now we rely on them for what I would call spot consulting.”
Project teams that listen to the needs of users and relay those issues to the project manager and to external consultants stand a better chance of early weaning. One of the most valuable contributions vendors and systems integrators have to offer is their experience with the project environment. “Ninety-five percent of our consultants’ time is spent working on projects,” says Stephen Thornton, director of services for Intentia Americas. “That’s a totally different environment than our customers are used to operating in. And we ensure that they understand what their commitments are in terms of delivering solutions in the project environment.”
North American Scientific’s Holbert conducted a risk analysis before guiding his company through its ERP implementation. He says two of the greatest risks to the implementation were the workforce’s lack of experience with integrated applications and its lack of familiarity with a project environment. “Other than myself, our CFO was the only other person in the organization who had worked with any type of integrated application, let alone installed one,” Holbert says. To mitigate those risks, he hammered the importance of communications. As project manager, Holbert, who also holds master’s degree in finance, says he sought to “bridge the dialogue between the technical and the functional.”
That type of vision is essential for an ERP project manager. At A.W. Chesterton, Wightman tells of a messy implementation that took place at the company in the mid-1990s. In that case, she says, three people selected the software package and “kind of rammed it down everybody’s throat.” This time, she says, she and the project team established acceptance at the grass roots level by holding project meetings before the selection of Intentia was finalized.
In addition to a 15-member implementation team and five Intentia consultants, A.W. Chesterton established a steering committee made up of the CFO, vice presidents, and division managers. “We made it clear to them that their role was keeping the project on track,” Wightman notes. As project manager (and an IT manager), Wightman emphasizes that her team never had to say no to the rest of the company—that responsibility rested with the steering committee. That decisionmaking structure and executive buy-in prevented the kind of employee vs. implementation team friction that hinders many ERP projects.
Wightman also held regular meetings with the steering committee to maintain open communications. Prior to the meetings, she would meet with each executive member individually to update them. That kept the meetings short. She had project members fill out time sheets, and she presented those numbers at each steering committee gathering. “I would throw up a slide indicating that 90% of the time committed to the project by this division was being done,” she says. “Another division might have only completed 30% of the time it committed to the project. The managers would look at the manager whose division had only contributed 30% of its commitment for that phase and say, ‘Hey, your people need to get with the program.’”
When issues were too small to relay to the steering committee but important enough to address, they were added to a Day Two list. “If we found something we wanted to implement but felt it was going to take too much time or we didn’t have enough experience, we threw it up on the Day Two list,” Wightman says. “Many times, people are afraid something is not going to get implemented. Once they saw it on that list, they knew that after the system went live, we would go back and start implementing all the things on the Day Two list. And we did; we stuck with it.” That way, divisions or smaller functional groups that don’t get all the functionality they want initially remain committed to the project.
That type of flexibility is critical to the success of the implementation. “We came in under budget and right on time,” says Holbert. “One of the phases was a month late, but overall we were on time. Still, our plan changed dramatically from day one, day 60, day 180 and so forth. A lot of companies don’t update plans.”
Thornton agrees, noting that companies tend to focus on cost and time overruns without balancing those changes against benefits. “You can talk about overruns on project budget without really addressing the potential goal you’re aiming for,” he says. “For example, let’s say you have a project that costs you $1 million, and during the project that cost increases to $1.2 million. If your original benefits were $2 million but now they’re $2.8 million, you shouldn’t lose sight of that.”
Wightman says her company increased its ERP budget, but, again, that decision was made at the steering committee level. As with most successful implementations, A.W. Chesterton used a phased approach, which helped keep scope creep in check. “It wasn’t like we had $1 million and then halfway through the project we used half of it,” Wightman adds. “Every phase, depending on the activities within that phase had a certain amount of consultant days and opportunity costs allocated to it. Since everything is tracked within each phase, it feels more like doing five mini-projects than one massive project.”
In addition to scope creep, which affects most large projects, there are several manufacturing specific ERP-implementation challenges. Thornton notes that resistance to change tends to be stronger among manufacturing companies. “Companies sometimes are steeped in customs and practice that don’t necessarily lend themselves to implementations of this nature,” he says. “I think there are cultural issues that need attention. I’m afraid people far too often overlook the change management requirements of an implementation.”
Mohan Thiruvadi, product marketing manager for Exact Software North America, worked for many years on the implementation side before he assumed his current role. He notes that manufacturers often require more training time for their users, particularly those on the shop floor. Manufacturing companies also tend to encounter more issues related to potential gaps in ERP capabilities (i.e., where the software fails to address a need). “There were always discussions on functionality and gaps,” says ADC Telecommunications’ Bridgeman. “Everybody felt they were different. When you looked into it, everybody usually wasn’t as different as they thought. So you really had to focus and understand what they were seeing to determine if they really had a gap. You have to be prepared to determine if there is a fundamental piece of their business that requires some development to support.”
There’s one final manufacturing-specific ERP-implementation challenge companies should address, once they achieve the kind of success evident at ADC. Bridgeman calls it the yawn factor. “When everything goes smoothly, you have to reinforce the fact that these projects are not lay-ups,” he adds. “Despite past successes and an effective implementation plan, you still need executive support, and the team still needs to be rewarded for its work.”
One size does not fit all when it comes to figuring out the costs, timing, and keys to success for an ERP implementation. Jill Rose reports.
There are a lot of nightmare ERP implementation stories out there. You’ve probably heard one or two. But for each of these stories, there is an equal amount of wisdom from people like Dan Bridgeman, director of business applications for ADC Telecommunications in Minneapolis.
Bridgeman, his team, and their colleagues have conducted more than 50 ERP deployments around the world since June 1997, thanks to a worldwide adoption of SAP and a spate of acquisitions by the $2.4 billion manufacturer of telecommunications equipment. Out of ADC’s experience has emerged a project plan that crystallizes the crucial components of successful ERP implementations among all sizes of manufacturing enterprises: a focus on business process; clear communications among project teams, executives, users, vendors, and consultants; and a healthy balance between discipline and flexibility.
Companies seeking to improve their ERP implementation processes tend to focus on money and time: what does it cost and how long will it take? The answer, inevitably, is the same: it depends. ADC will spend about $1 million on its current four-month SAP deployment at a recently acquired company with roughly 2,000 fairly dispersed users. A.W. Chesterton Company, a private manufacturer of industrial fluid sealing, hydraulic/pneumatic, and maintenance products, invested about $2 million during its 20-month, global implementation of an Intentia ERP system. Small companies can conduct a rapid implementation within two months for less than $100,000 through Exact Software North America, or they can opt for a $150,000 investment during a three- to six-month Exact Software implementation with far greater levels of customization and training. Again, it all depends.
“We can take two manufacturers based in Ohio, both making metal fasteners,” says William Wohl, a spokesperson for SAP America in Newtown Square, PA. “Suppose both companies need to create an enterprise system to do what most people think of when they think of ERP. Both companies will approach the project differently; both will wind up spending different amounts of money. Both projects will take different lengths of time to complete. And both could have very different outcomes.” That’s because the success of any ERP installation hinges on the redesign of business processes.
“The most important step you take is not the installation of software on a CD, but the mapping of basic business processes to best practices—or for some companies, the first real identification of what business processes are,” says Wohl.
If one of the world’s leading technology solutions companies emphasizes business process over technology, there must be something to it. And SAP is not alone. Syspro Group, one of the leading ERP providers to the manufacturing sector, first published its implementation methodology, STARS (Structured Technique to Achieve Rapid Solution), in 1998. Earlier this year, Syspro completely rewrote STARS. The new version is business process-based, whereas the first two versions of the methodology were “impact modular based” (i.e., focused on the ERP system’s groupings of financial, distribution, and manufacturing capabilities).
“We found that people weren’t thinking modularly,” says Syspro Vice President of Marketing Joey Benadretti. “They were thinking in terms of process flows. What’s a sales flow? What’s a purchasing flow? What’s the flow on the shop floor? That’s how a manufacturing company addresses it. We believe we have arrived at the point, from an implementation perspective, where we need to look at the business process phases rather than from the impact modular based perspective. Reengineering internal processes is a major step forward for companies that want to gain from the information technology. But there is no reason to implement a new system if you’re not going to take advantage of the technology and the new processes you can perform to save time and money.”
A.W. Chesterton, for example, assigned “process owners” roles as part of its implementation of Intentia’s Movex ERP system. “We had somebody in charge of finance across the company, somebody in charge of customer order maintenance across the company, and so on,” says Anne Wightman, information system operation manager for A.W. Chesterton in Stoneham, Ma. “The tricky part was that we had five different manufacturing divisions at the time. So, even though we had one person in charge of manufacturing as a process owner, they had to make sure that those five different divisions were represented well enough in their own unique areas so they could work with the way the system was being configured. Process owners operated at the highest level. If we had an issue in manufacturing, everybody knew that Paul was the person to go to, and he kept track of where we stood and tracked the issue log.”
Chesterton used Intentia’s Implex implementation methodology. Bridgeman notes that ADC’s methodology closely resembles SAP’s Solution Maps methodology. And Chris Holbert, director of IT for North American Scientific Inc., a manufacturer of radioactive medical devices in Chatsworth, Calif., says Exact Software was “very helpful in providing an overview of its ERP functionality and what is possible through the software.” These and other examples signify the trust that companies bestow on their vendors in successful implementations.
Part and parcel with that trust, however, is the recognition that consulting services, from vendors or their implementation partners, can make up a hefty chunk of the final bill. The successful ERP implementations at A.W. Chesterton and ADC Telecommunications included careful monitoring of consulting hours.
Responsible vendors and consultants respond to this need by transferring their knowledge as efficiently as possible. Early on in ADC’s ERP implementation activity, systems integration and IT consulting firm CSC, along with SAP consultants, were much more involved in the process. “As we gathered that knowledge, we weaned ourselves because that work can get very expensive,” says Bridgeman. “We still gain significant value from calling on them, but now we rely on them for what I would call spot consulting.”
Project teams that listen to the needs of users and relay those issues to the project manager and to external consultants stand a better chance of early weaning. One of the most valuable contributions vendors and systems integrators have to offer is their experience with the project environment. “Ninety-five percent of our consultants’ time is spent working on projects,” says Stephen Thornton, director of services for Intentia Americas. “That’s a totally different environment than our customers are used to operating in. And we ensure that they understand what their commitments are in terms of delivering solutions in the project environment.”
North American Scientific’s Holbert conducted a risk analysis before guiding his company through its ERP implementation. He says two of the greatest risks to the implementation were the workforce’s lack of experience with integrated applications and its lack of familiarity with a project environment. “Other than myself, our CFO was the only other person in the organization who had worked with any type of integrated application, let alone installed one,” Holbert says. To mitigate those risks, he hammered the importance of communications. As project manager, Holbert, who also holds master’s degree in finance, says he sought to “bridge the dialogue between the technical and the functional.”
That type of vision is essential for an ERP project manager. At A.W. Chesterton, Wightman tells of a messy implementation that took place at the company in the mid-1990s. In that case, she says, three people selected the software package and “kind of rammed it down everybody’s throat.” This time, she says, she and the project team established acceptance at the grass roots level by holding project meetings before the selection of Intentia was finalized.
In addition to a 15-member implementation team and five Intentia consultants, A.W. Chesterton established a steering committee made up of the CFO, vice presidents, and division managers. “We made it clear to them that their role was keeping the project on track,” Wightman notes. As project manager (and an IT manager), Wightman emphasizes that her team never had to say no to the rest of the company—that responsibility rested with the steering committee. That decisionmaking structure and executive buy-in prevented the kind of employee vs. implementation team friction that hinders many ERP projects.
Wightman also held regular meetings with the steering committee to maintain open communications. Prior to the meetings, she would meet with each executive member individually to update them. That kept the meetings short. She had project members fill out time sheets, and she presented those numbers at each steering committee gathering. “I would throw up a slide indicating that 90% of the time committed to the project by this division was being done,” she says. “Another division might have only completed 30% of the time it committed to the project. The managers would look at the manager whose division had only contributed 30% of its commitment for that phase and say, ‘Hey, your people need to get with the program.’”
When issues were too small to relay to the steering committee but important enough to address, they were added to a Day Two list. “If we found something we wanted to implement but felt it was going to take too much time or we didn’t have enough experience, we threw it up on the Day Two list,” Wightman says. “Many times, people are afraid something is not going to get implemented. Once they saw it on that list, they knew that after the system went live, we would go back and start implementing all the things on the Day Two list. And we did; we stuck with it.” That way, divisions or smaller functional groups that don’t get all the functionality they want initially remain committed to the project.
That type of flexibility is critical to the success of the implementation. “We came in under budget and right on time,” says Holbert. “One of the phases was a month late, but overall we were on time. Still, our plan changed dramatically from day one, day 60, day 180 and so forth. A lot of companies don’t update plans.”
Thornton agrees, noting that companies tend to focus on cost and time overruns without balancing those changes against benefits. “You can talk about overruns on project budget without really addressing the potential goal you’re aiming for,” he says. “For example, let’s say you have a project that costs you $1 million, and during the project that cost increases to $1.2 million. If your original benefits were $2 million but now they’re $2.8 million, you shouldn’t lose sight of that.”
Wightman says her company increased its ERP budget, but, again, that decision was made at the steering committee level. As with most successful implementations, A.W. Chesterton used a phased approach, which helped keep scope creep in check. “It wasn’t like we had $1 million and then halfway through the project we used half of it,” Wightman adds. “Every phase, depending on the activities within that phase had a certain amount of consultant days and opportunity costs allocated to it. Since everything is tracked within each phase, it feels more like doing five mini-projects than one massive project.”
In addition to scope creep, which affects most large projects, there are several manufacturing specific ERP-implementation challenges. Thornton notes that resistance to change tends to be stronger among manufacturing companies. “Companies sometimes are steeped in customs and practice that don’t necessarily lend themselves to implementations of this nature,” he says. “I think there are cultural issues that need attention. I’m afraid people far too often overlook the change management requirements of an implementation.”
Mohan Thiruvadi, product marketing manager for Exact Software North America, worked for many years on the implementation side before he assumed his current role. He notes that manufacturers often require more training time for their users, particularly those on the shop floor. Manufacturing companies also tend to encounter more issues related to potential gaps in ERP capabilities (i.e., where the software fails to address a need). “There were always discussions on functionality and gaps,” says ADC Telecommunications’ Bridgeman. “Everybody felt they were different. When you looked into it, everybody usually wasn’t as different as they thought. So you really had to focus and understand what they were seeing to determine if they really had a gap. You have to be prepared to determine if there is a fundamental piece of their business that requires some development to support.”
There’s one final manufacturing-specific ERP-implementation challenge companies should address, once they achieve the kind of success evident at ADC. Bridgeman calls it the yawn factor. “When everything goes smoothly, you have to reinforce the fact that these projects are not lay-ups,” he adds. “Despite past successes and an effective implementation plan, you still need executive support, and the team still needs to be rewarded for its work.”
Don't Modify Your Enterprise Application..
Don't Modify Your Enterprise Application
Unless you like to spend a lot of money and effort to permanently fix temporary problems.
Nov 06, 2006
By Philippe Beaurain, IFS North America
Remember the first time you picked up a cup of coffee and took a sip? It was probably unlike anything you ever tasted before. If you were committed to choking down the whole cup (perhaps to stay awake for a late-night study session) the first thing you probably did was dump a large amount of sugar or cream into that coffee to make it more palatable. Over time, as you became more accustomed to the taste of coffee, you no longer needed cream and sugar. This not only reduced the number of calories in that jolt of caffeine, but allowed you to appreciate the flavor of the beans, the quality of the roast and the subtle aroma.
That first cup of coffee can teach us a valuable lesson when it comes to managing the implementation of an enterprise application.
At first glance, a new enterprise application will seem strange to end-users within your company, and those end users will likely come to you with a laundry list of modifications, often designed to make the application more similar to what they have seen and experienced before. However, while the cream and sugar used to doctor up that first cup of coffee were almost free, modifying enterprise applications can add millions of dollars to the total cost of ownership (TCO) of that application.
Modifications increase TCO in three ways:
Modifications increase the cost of implementation as custom programming becomes necessary to meet the specific demands.
Modifications increase the cost of service because a software company’s personnel must get up to speed on and support the idiosyncrasies of the modification as well as the standard software.
Modifications increase the cost of upgrades, as the modification must in most cases be uplifted each time a new version of the software is implemented. So across the lifecycle of an enterprise software package, modifications increase TCO.
While they can cost millions, many modifications are like the cream and sugar in that after a while they become unnecessary as users become more familiar with the application. We all know there is no caffeine in cream or sugar – and similarly the modifications made to enterprise applications generally do not improve the ability of the software to meet real business needs!
Increased Cost, No Gain
If your company decides to implement an enterprise application, it is to achieve specific, rational goals. You may need to better coordinate projects and processes across departments, or streamline financial reporting and analysis. Or perhaps you want to allow closer collaboration with customers and suppliers, or to enable efficiencies that make your company more competitive. You choose the application and vendor that you feel will do the best job helping you reach your business goals.
In some cases, a company may choose an enterprise application that requires extensive modification in order to meet their basic needs. This usually means that the wrong vendor or application was selected. As competitive pressures intensify in this age of globalization, specific vertical industries and business models require more specific functionality. Rather than modify the wrong application, it likely makes more sense to choose the right application—one that is based on best practices proven to improve the efficiency of a business like your own.
Hands-On Versus Bird’s Eye
But even when customers choose an application for sound business reasons, senior management often gives end users of the application, sometimes unconsciously, the opportunity to suggest modifications, and these modifications might lead them astray of their original objectives.
Hands-on users of an enterprise application typically have knowledge or understanding only of their own role in the organization rather than a broad understanding of the business as a whole. They may not be privy to the business reasoning for changing the tools they work with every day. Many software modifications that employees insist are necessary for them to continue their current level of productivity are designed to preserve the status quo and would do little to help the company reach its high-level goals. Individual employees’ optimization of their own work might represent a sub-optimization at the company level!
At my company, in situations where our customers give us long lists of "must-have" modifications, we have found that if we can convince them to run the software as-is for 90 days, the modifications drop off the list one-by-one. This is because employees’ paradigms shift from the old to the new system. They find that the new software system can in fact do what the old one could do—and more. The new software environment is no longer a threat and becomes a familiar, normal part of life—like that morning cup of coffee.
Senior managers are always involved in the selection of an enterprise application—but this dynamic is one reason that they really need to stay involved in the implementation. Their bird’s-eye view of the company’s operations gives them the perspective necessary to determine the true needs of the business.
Mods to Watch Out For
Each implementation of an enterprise application and each business situation brings with it unique challenges, but here is a short list of spurious modifications to watch out for.
Duplicating the Legacy System. "In the old system …" are four words to watch out for when employees request modifications. It is only natural that users of a system become attached to that system, and would request modifications to make a new software package look and feel like the old one.
Data Entry Aids. This is a "convenience modification" that formats or manipulates data as it is entered in the system so users can truncate information, leave out special characters or in other ways shave time off of data entry.
The "Do My Job" Button. Another "convenience mod" involves stringing various elements of functionality together. Creation of an "add parts" button, an "add purchase orders" or an "add customers" button are examples. But after using a new enterprise software package for a period of time, these expensive "Wizards" quickly become obsolete as employees master their new environment.
Unless you like to spend a lot of money and effort to permanently fix temporary problems.
Nov 06, 2006
By Philippe Beaurain, IFS North America
Remember the first time you picked up a cup of coffee and took a sip? It was probably unlike anything you ever tasted before. If you were committed to choking down the whole cup (perhaps to stay awake for a late-night study session) the first thing you probably did was dump a large amount of sugar or cream into that coffee to make it more palatable. Over time, as you became more accustomed to the taste of coffee, you no longer needed cream and sugar. This not only reduced the number of calories in that jolt of caffeine, but allowed you to appreciate the flavor of the beans, the quality of the roast and the subtle aroma.
That first cup of coffee can teach us a valuable lesson when it comes to managing the implementation of an enterprise application.
At first glance, a new enterprise application will seem strange to end-users within your company, and those end users will likely come to you with a laundry list of modifications, often designed to make the application more similar to what they have seen and experienced before. However, while the cream and sugar used to doctor up that first cup of coffee were almost free, modifying enterprise applications can add millions of dollars to the total cost of ownership (TCO) of that application.
Modifications increase TCO in three ways:
Modifications increase the cost of implementation as custom programming becomes necessary to meet the specific demands.
Modifications increase the cost of service because a software company’s personnel must get up to speed on and support the idiosyncrasies of the modification as well as the standard software.
Modifications increase the cost of upgrades, as the modification must in most cases be uplifted each time a new version of the software is implemented. So across the lifecycle of an enterprise software package, modifications increase TCO.
While they can cost millions, many modifications are like the cream and sugar in that after a while they become unnecessary as users become more familiar with the application. We all know there is no caffeine in cream or sugar – and similarly the modifications made to enterprise applications generally do not improve the ability of the software to meet real business needs!
Increased Cost, No Gain
If your company decides to implement an enterprise application, it is to achieve specific, rational goals. You may need to better coordinate projects and processes across departments, or streamline financial reporting and analysis. Or perhaps you want to allow closer collaboration with customers and suppliers, or to enable efficiencies that make your company more competitive. You choose the application and vendor that you feel will do the best job helping you reach your business goals.
In some cases, a company may choose an enterprise application that requires extensive modification in order to meet their basic needs. This usually means that the wrong vendor or application was selected. As competitive pressures intensify in this age of globalization, specific vertical industries and business models require more specific functionality. Rather than modify the wrong application, it likely makes more sense to choose the right application—one that is based on best practices proven to improve the efficiency of a business like your own.
Hands-On Versus Bird’s Eye
But even when customers choose an application for sound business reasons, senior management often gives end users of the application, sometimes unconsciously, the opportunity to suggest modifications, and these modifications might lead them astray of their original objectives.
Hands-on users of an enterprise application typically have knowledge or understanding only of their own role in the organization rather than a broad understanding of the business as a whole. They may not be privy to the business reasoning for changing the tools they work with every day. Many software modifications that employees insist are necessary for them to continue their current level of productivity are designed to preserve the status quo and would do little to help the company reach its high-level goals. Individual employees’ optimization of their own work might represent a sub-optimization at the company level!
At my company, in situations where our customers give us long lists of "must-have" modifications, we have found that if we can convince them to run the software as-is for 90 days, the modifications drop off the list one-by-one. This is because employees’ paradigms shift from the old to the new system. They find that the new software system can in fact do what the old one could do—and more. The new software environment is no longer a threat and becomes a familiar, normal part of life—like that morning cup of coffee.
Senior managers are always involved in the selection of an enterprise application—but this dynamic is one reason that they really need to stay involved in the implementation. Their bird’s-eye view of the company’s operations gives them the perspective necessary to determine the true needs of the business.
Mods to Watch Out For
Each implementation of an enterprise application and each business situation brings with it unique challenges, but here is a short list of spurious modifications to watch out for.
Duplicating the Legacy System. "In the old system …" are four words to watch out for when employees request modifications. It is only natural that users of a system become attached to that system, and would request modifications to make a new software package look and feel like the old one.
Data Entry Aids. This is a "convenience modification" that formats or manipulates data as it is entered in the system so users can truncate information, leave out special characters or in other ways shave time off of data entry.
The "Do My Job" Button. Another "convenience mod" involves stringing various elements of functionality together. Creation of an "add parts" button, an "add purchase orders" or an "add customers" button are examples. But after using a new enterprise software package for a period of time, these expensive "Wizards" quickly become obsolete as employees master their new environment.
To customise or not to customise
It’s a thorny question that has baffled many.
Ipshita Basu examines the pros and cons of customising ERP.
Your company has decided to go in for an ERP application. The product is selected and the implementation begins. The ERP vendor has promised the moon in its sales pitch. The future with ERP is painted in varied hues. Slowly, however, users realise that certain processes, forms or reports are not in conjunction with company practices. End-users start displaying a negative attitude towards the implementation and grumble about the features. How do we resolve such discrepancies?
Solution or inviting trouble?
The first thought that comes to a layman’s mind is to modify the software. Let’s tinker with the database structure and the layouts to suit our needs. This might solve the problem. Or it could also be the beginning of a series of wrong moves which might jeopardise the entire implementation. The choice is in the hands of the company’s project manager (PM). Every modification in the package will entail some cost—man, machine and money. Generally, the SMB ERP vendors will prefer some modifications without explaining the flip side of these. User companies also lack the expertise to visualise the obstacles in depth. Should we customise or not, and if yes, then to what degree—this is an issue which should be dealt with in depth and diversity before pursuing as it will have far-reaching effects.
To customise…
Most ERP products are generic. There are many industry-specific solutions available, which are designed using industry best practices. Many have processes that help companies comply with ISO certification requirements. They are justified in using a particular workflow, layout or method. Thus, it is prudent to follow the processes. The fact is—it is not always possible to do so. Companies have various terms and conditions with suppliers, customers, divisions, strategic business units, third parties, etc. It is not feasible to go for an entire makeover. Hence, some customisation is needed to suit the company’s needs. Optimal customisation is subjective with no definite rules.
Commonly customisation occurs in the case of reports and layouts. Companies need certain data in reports for decision-making. Currently, this might be achieved by manual spreadsheets. The content of reports defines what we should have in the data-entry forms. If certain input is not available or cannot be calculated, then it cannot be displayed in the reports. Hence, it is imperative that the reports are modified.
The stages of a process can be shortened. A normal material requisition cycle has stages such as requisition, quotation, comparison, purchase order, goods receipt, quality check and payment. We have the choice of following all the steps or starting from a particular step or even omitting a step. This will increase the efficiency of the system. Depending upon the size of the company, certain processes may be redundant as the same person might be handling both. For example, creating a purchase requisition and authorising it.
Companies have different structures in terms of sister-concerns, branches and sub-divisions. These are created for certain competitive as well as regulatory advantage. Though it is recommended that during evaluation, features should be checked in accordance with the company, certain issues might still be left out. Modifying a structure alone is not possible; systems and strategies will have to be modified too. Hence, it is better to make changes in the ERP flow itself. The extent of customisation should be discussed by the PM with the end-user and the ERP consultant. It should not cause any hindrances at later stages of the implementation of the same module or of related modules. After all we are modifying an integrated system. Each modification can have a ripple effect across other areas.
…or not to customise
What do ERP consultants advise? Do not customise and modify the application! There are several reasons for this.
Firstly, customisation is subjective. People do not understand where to draw the line. End-users are not always technically equipped to understand the far-reaching implications of the changes that they are demanding. The normal attitude is “Since we are paying for the product, do as we say.” Many of them are not able to articulate their requirement, as sometimes they do not understand what they want.
There is a cost to customisation. The ERP vendor will charge you for the modifications either on man-days or on the number of changes. The implementation time will also increase. This can lead to a serious increase in the project cost though it might not make it unviable. Is it really necessary to change a particular layout? It is essential to consider these issues before embarking on a customisation spree. ERP implementation is the right time for Business Process Re-engineering. Instead of modifying an application, it is better to modify the company processes as per the ERP standards since they already have the best practices incorporated in them.
People change on both sides. The end-user or the ERP consultant might quit. This is quite common and a major cause of concern. Everyone who has worked with some ERP might have faced this situation at least once. The next person in-charge might have to start from scratch to understand what customisation has been initiated and why. There is a chance that he might not find it necessary and hence, order a rollback. Perspective is never correct or incorrect, but two persons might not share the same perspective.
This problem is further compounded by the lack of proper documentation and the tracking of the changes which have been initiated.
Customised coding is again a costly affair. Generally, companies do not have skilled programmers so they have to depend on the ERP vendor. These codes require maintenance and updating. Programming logic also differs from one person to another. There is always a risk of destabilising the core application. Is it really worth it?
Now comes the most crucial part. You have customised your ERP to suit your needs. The government issues some changes in the tax structure or the ERP vendor has incorporated some additional features. They issue a patch or an upgrade of their product to their customers. Will it work for you? No. It will not work for your installation because the basic structure has been modified. What is the recourse? You have to again customise. The custom codes will have to be modified. Hence, it goes into an infinite loop.
Therefore, the answer is to...
Customisation of ERP is a complex matter, and it should be used as a fire-fighting tactic. It is a strategic matter rather than operational. It has both pros and cons, but requires careful analysis, planning and execution considering the long-term vision of the company. The PM has to keep tight control over end-users and their demands when it comes to any modification. The ERP consultants should be considered as a part of the team, and their views should be heeded. They know their product best, and most of them have experience in implementation. They also have exposure to the business processes of other clients which can be emulated to solve a problem. Many ERP vendors have functional experts to implement a certain module. They will invariably have some logical solution to problems requiring modifications. We cannot deny that some customisation is required in the best of applications, but to what extent it is justifiable and viable is highly debatable. Modifying the report layouts is acceptable especially in case of financial information which can be used for good MIS. The core structure of the application should not be modified under any circumstances. ERP vendors generate revenue by undertaking customisation. They earn in addition to the cost of the product. The interest of the company (client) is not their top priority.
The PM should assess the amount of time, money and manpower that a particular modification will require before allowing it. Once certain changes are made, every activity should be thoroughly documented. The changes should be initiated through a central command. End-users should not be allowed to make their demands to consultants. Customisation can make or break your implementation and affect the fate of your project. Strike the right balance.
Ipshita Basu examines the pros and cons of customising ERP.
Your company has decided to go in for an ERP application. The product is selected and the implementation begins. The ERP vendor has promised the moon in its sales pitch. The future with ERP is painted in varied hues. Slowly, however, users realise that certain processes, forms or reports are not in conjunction with company practices. End-users start displaying a negative attitude towards the implementation and grumble about the features. How do we resolve such discrepancies?
Solution or inviting trouble?
The first thought that comes to a layman’s mind is to modify the software. Let’s tinker with the database structure and the layouts to suit our needs. This might solve the problem. Or it could also be the beginning of a series of wrong moves which might jeopardise the entire implementation. The choice is in the hands of the company’s project manager (PM). Every modification in the package will entail some cost—man, machine and money. Generally, the SMB ERP vendors will prefer some modifications without explaining the flip side of these. User companies also lack the expertise to visualise the obstacles in depth. Should we customise or not, and if yes, then to what degree—this is an issue which should be dealt with in depth and diversity before pursuing as it will have far-reaching effects.
To customise…
Most ERP products are generic. There are many industry-specific solutions available, which are designed using industry best practices. Many have processes that help companies comply with ISO certification requirements. They are justified in using a particular workflow, layout or method. Thus, it is prudent to follow the processes. The fact is—it is not always possible to do so. Companies have various terms and conditions with suppliers, customers, divisions, strategic business units, third parties, etc. It is not feasible to go for an entire makeover. Hence, some customisation is needed to suit the company’s needs. Optimal customisation is subjective with no definite rules.
Commonly customisation occurs in the case of reports and layouts. Companies need certain data in reports for decision-making. Currently, this might be achieved by manual spreadsheets. The content of reports defines what we should have in the data-entry forms. If certain input is not available or cannot be calculated, then it cannot be displayed in the reports. Hence, it is imperative that the reports are modified.
The stages of a process can be shortened. A normal material requisition cycle has stages such as requisition, quotation, comparison, purchase order, goods receipt, quality check and payment. We have the choice of following all the steps or starting from a particular step or even omitting a step. This will increase the efficiency of the system. Depending upon the size of the company, certain processes may be redundant as the same person might be handling both. For example, creating a purchase requisition and authorising it.
Companies have different structures in terms of sister-concerns, branches and sub-divisions. These are created for certain competitive as well as regulatory advantage. Though it is recommended that during evaluation, features should be checked in accordance with the company, certain issues might still be left out. Modifying a structure alone is not possible; systems and strategies will have to be modified too. Hence, it is better to make changes in the ERP flow itself. The extent of customisation should be discussed by the PM with the end-user and the ERP consultant. It should not cause any hindrances at later stages of the implementation of the same module or of related modules. After all we are modifying an integrated system. Each modification can have a ripple effect across other areas.
…or not to customise
What do ERP consultants advise? Do not customise and modify the application! There are several reasons for this.
Firstly, customisation is subjective. People do not understand where to draw the line. End-users are not always technically equipped to understand the far-reaching implications of the changes that they are demanding. The normal attitude is “Since we are paying for the product, do as we say.” Many of them are not able to articulate their requirement, as sometimes they do not understand what they want.
There is a cost to customisation. The ERP vendor will charge you for the modifications either on man-days or on the number of changes. The implementation time will also increase. This can lead to a serious increase in the project cost though it might not make it unviable. Is it really necessary to change a particular layout? It is essential to consider these issues before embarking on a customisation spree. ERP implementation is the right time for Business Process Re-engineering. Instead of modifying an application, it is better to modify the company processes as per the ERP standards since they already have the best practices incorporated in them.
People change on both sides. The end-user or the ERP consultant might quit. This is quite common and a major cause of concern. Everyone who has worked with some ERP might have faced this situation at least once. The next person in-charge might have to start from scratch to understand what customisation has been initiated and why. There is a chance that he might not find it necessary and hence, order a rollback. Perspective is never correct or incorrect, but two persons might not share the same perspective.
This problem is further compounded by the lack of proper documentation and the tracking of the changes which have been initiated.
Customised coding is again a costly affair. Generally, companies do not have skilled programmers so they have to depend on the ERP vendor. These codes require maintenance and updating. Programming logic also differs from one person to another. There is always a risk of destabilising the core application. Is it really worth it?
Now comes the most crucial part. You have customised your ERP to suit your needs. The government issues some changes in the tax structure or the ERP vendor has incorporated some additional features. They issue a patch or an upgrade of their product to their customers. Will it work for you? No. It will not work for your installation because the basic structure has been modified. What is the recourse? You have to again customise. The custom codes will have to be modified. Hence, it goes into an infinite loop.
Therefore, the answer is to...
Customisation of ERP is a complex matter, and it should be used as a fire-fighting tactic. It is a strategic matter rather than operational. It has both pros and cons, but requires careful analysis, planning and execution considering the long-term vision of the company. The PM has to keep tight control over end-users and their demands when it comes to any modification. The ERP consultants should be considered as a part of the team, and their views should be heeded. They know their product best, and most of them have experience in implementation. They also have exposure to the business processes of other clients which can be emulated to solve a problem. Many ERP vendors have functional experts to implement a certain module. They will invariably have some logical solution to problems requiring modifications. We cannot deny that some customisation is required in the best of applications, but to what extent it is justifiable and viable is highly debatable. Modifying the report layouts is acceptable especially in case of financial information which can be used for good MIS. The core structure of the application should not be modified under any circumstances. ERP vendors generate revenue by undertaking customisation. They earn in addition to the cost of the product. The interest of the company (client) is not their top priority.
The PM should assess the amount of time, money and manpower that a particular modification will require before allowing it. Once certain changes are made, every activity should be thoroughly documented. The changes should be initiated through a central command. End-users should not be allowed to make their demands to consultants. Customisation can make or break your implementation and affect the fate of your project. Strike the right balance.
What are the benefits and disadvantages of implementing ERP software?
Advantages:
Integration
Integration can be the highest benefit of them all. The only real project aim for implementing ERP is reducing data redudancy and redudant data entry. If this is set as a goal, to automate inventory posting to G/L, then it might be a successful project. Those companies where integration is not so important or even dangerous, tend to have a hard time with ERP. ERP does not improve the individual efficiency of users, so if they expect it, it will be a big disappointment. ERP improves the cooperation of users.
Efficiency
Generally, ERP software focuses on integration and tend to not care about the daily needs of people. I think individual efficiency can suffer by implementing ERP. the big question with ERP is whether the benefit of integration and cooperation can make up for the loss in personal efficiency or not.
Cost reduction
It reduces cost only if the company took accounting and reporting seriously even before implementation and had put a lot of manual effort in it. If they didn't care about it, if they just did some simple accounting to fill mandatory statements and if internal reporting did not exists of has not been fincancially-oriented, then no cost is reduced.
Less personnel
Same as above. Less reporting or accounting personnel, but more sales assistants etc.
Accuracy
No. People are accurate, not software. What ERP does is makes the lives of inaccurate people or organization a complete hell and maybe forces them to be accurate (which means hiring more people or distributing work better), or it falls.
Disadvantages:
Expensive
This entails software, hardware, implementation, consultants, training, etc. Or you can hire a programmer or two as an employee and only buy business consulting from an outside source, do all customization and end-user training inside. That can be cost-effective.
Not very flexible
It depends. SAP can be configured to almost anything. In Navision one can develop almost anything in days. Other software may not be flexible.
Integration
Integration can be the highest benefit of them all. The only real project aim for implementing ERP is reducing data redudancy and redudant data entry. If this is set as a goal, to automate inventory posting to G/L, then it might be a successful project. Those companies where integration is not so important or even dangerous, tend to have a hard time with ERP. ERP does not improve the individual efficiency of users, so if they expect it, it will be a big disappointment. ERP improves the cooperation of users.
Efficiency
Generally, ERP software focuses on integration and tend to not care about the daily needs of people. I think individual efficiency can suffer by implementing ERP. the big question with ERP is whether the benefit of integration and cooperation can make up for the loss in personal efficiency or not.
Cost reduction
It reduces cost only if the company took accounting and reporting seriously even before implementation and had put a lot of manual effort in it. If they didn't care about it, if they just did some simple accounting to fill mandatory statements and if internal reporting did not exists of has not been fincancially-oriented, then no cost is reduced.
Less personnel
Same as above. Less reporting or accounting personnel, but more sales assistants etc.
Accuracy
No. People are accurate, not software. What ERP does is makes the lives of inaccurate people or organization a complete hell and maybe forces them to be accurate (which means hiring more people or distributing work better), or it falls.
Disadvantages:
Expensive
This entails software, hardware, implementation, consultants, training, etc. Or you can hire a programmer or two as an employee and only buy business consulting from an outside source, do all customization and end-user training inside. That can be cost-effective.
Not very flexible
It depends. SAP can be configured to almost anything. In Navision one can develop almost anything in days. Other software may not be flexible.
Migrating to an ERP System
ByRoshmi Choudhury, Officer (IT)
Numaligarh Refinery Limited
Abstract
To compete in this business world, companies need better information management of thecompany’s data- a management that will help in better analysis of the processes involved.
Companies are however having a difficult time integrating and correlating data fromvarious software applications and are looking forward to a single application. This iswhere the company can employ Enterprise Resource Planning (ERP) Software.
Thispaper discusses the factors that should be considered while migrating to an ERP system.What is ERP?ERP generally refers to a software that supports a wide set of activities which helps thecompany manage its important functions like production, marketing, inventory, financeand human resource management. As such, ERP consists of a multi-module application,which allows data to flow from one module to the other.
It therefore not only integratesthe business processes, but also offers intelligent information by correlating data fromvarious modules.Catering to changing technologiesWhen deciding for an ERP solution, many factors come into play- the most important isthat the solution should serve the company for a longer term. That is to say, the solutionshould be able to adapt itself to the changing technologies like operating systems and newhardware features.
Most companies like JD Edwards, SAP, Ramco, etc offer suchupgrades, they have teams that cater to the changing needs in the software. All that isrequired is the application of a service pack.Connecting to heterogeneous environmentsIn this changing business world, companies are being bought and sold. It is likely that acompany will be sold off or may merge with some other company. It may so happen thatthese companies may be using different ERP packages. These ERP packages should nowbe able to work together.
ERP solutions like SAP have offered technologies like webenabledservices and exchanging technologies that help integrate these completelydifferent ERP environments.Minimizing supportA bulk of the IT budget in a company is spent not on new developments but on support.Having an ERP system minimizes support. At most, a two-member team is required forgenerating reports and solving minor problems that surfaces up when a lot of varied datais in the database. This way a company could spend less on support and divert the moneyin purchasing new capabilities.
Choice of the databaseThe database should be meticulously chosen because a lot depends on it. It is the choiceof the database that determines the performance of the ERP system. Server database thatruns on a multi-user platform is required for an ERP application. Server databases containmechanisms that ensure reliability and consistency of data. The primary factor thatshould be looked for is the concurrency model. The two most commonly used serverdatabases are Microsoft SQL server and Oracle. Both have their own advantages anddisadvantages.
They differ widely in terms of the concurrency model. Oracle provides amulti version read consistency with no read locks and no dirty reads. Readers do notblock writers and writers do not block readers. In Microsoft SQL server, read consistencyis not available. It requires shared read locks to avoid dirty reads, if locks are not shared,dirty reads are possible. Also readers block writers and writers’ block readers. Deadlockscan be a serious issue with Microsoft SQL server, which escalates row-level locks, totable-level locks depending on the transaction’s volume.
To the user, the applicationsimply hangs. These unpleasant deadlock situations can result in aborting one or more ofthe concurrent users. Oracle, on the other hand, does not escalate row level locking.Microsoft SQL server is easier to use, easier to manage, less complex and requires lotless tuning than Oracle and is an excellent choice on windows platform. For crossplatform support, Oracle is an excellent choice, which runs very well both on windowsand Linux platforms.
Most ERP solutions are built on both these platforms, and it is up tothe customer to decide the database of their choice.ERP system securityPerhaps the most important module in an ERP application is the security module thatcreates logins and grants select, update, insert, delete, and execute etc rights to thevarious database objects such as tables and stored procedures. Most ERP solutionsrestrict user from directly accessing tables.
The user can perform operations on a table viaa stored procedure and these stored procedures have many validation checks for the data.Also, the idea is to pass the entire logic to back-end stored procedures so that debuggingand alterations become easy for the IT team. Another feature that should be looked for inthe security module is password encryption for the user logins. Password encryptionprevents direct access to the database servers thereby preventing malicious users fromgaining access to the servers. The user can only access the server through the ERPsoftware.
Transiting from an existing ERP system to a new oneThe new ERP provider should be able to migrate the existing ERP data to its new systemwith minimal effort, that is, by using data translators, scripts and useful programmingtechniques. The data should make sense in the new ERP system. Also the ERP providershould audit the data to ensure its integrity before making the system live. If the data isnot suitable for transfer, the ERP provider should perform initialization techniques likecalculating the opening balance amount for the new system, for inventory it can calculatethe opening stock for each of the items, etc.
Will the ERP provider support customization?This is a question frequently asked. It should be noted that no two business processes arealike. An ERP solution that suffices for a company may not be the be all and end allsolution for another company. At some point of time, customization is required. Thecustomization should also remain intact for future upgrades of the software. The factorthat should be looked upon is whether the ERP provider is capable of doing this.
TheERP solution should also have builder tools for creating new forms and report writertools for generating new reports. By having this, some customization can be done at theuser end also.
References
• “SAP ERP Upgrade: Management Strategies” by Larstan Business Reports
• “Technical Comparison of Oracle 9i Database vs. SQL Server 2000: Focus onPerformance” – An Oracle White Paper
Numaligarh Refinery Limited
Abstract
To compete in this business world, companies need better information management of thecompany’s data- a management that will help in better analysis of the processes involved.
Companies are however having a difficult time integrating and correlating data fromvarious software applications and are looking forward to a single application. This iswhere the company can employ Enterprise Resource Planning (ERP) Software.
Thispaper discusses the factors that should be considered while migrating to an ERP system.What is ERP?ERP generally refers to a software that supports a wide set of activities which helps thecompany manage its important functions like production, marketing, inventory, financeand human resource management. As such, ERP consists of a multi-module application,which allows data to flow from one module to the other.
It therefore not only integratesthe business processes, but also offers intelligent information by correlating data fromvarious modules.Catering to changing technologiesWhen deciding for an ERP solution, many factors come into play- the most important isthat the solution should serve the company for a longer term. That is to say, the solutionshould be able to adapt itself to the changing technologies like operating systems and newhardware features.
Most companies like JD Edwards, SAP, Ramco, etc offer suchupgrades, they have teams that cater to the changing needs in the software. All that isrequired is the application of a service pack.Connecting to heterogeneous environmentsIn this changing business world, companies are being bought and sold. It is likely that acompany will be sold off or may merge with some other company. It may so happen thatthese companies may be using different ERP packages. These ERP packages should nowbe able to work together.
ERP solutions like SAP have offered technologies like webenabledservices and exchanging technologies that help integrate these completelydifferent ERP environments.Minimizing supportA bulk of the IT budget in a company is spent not on new developments but on support.Having an ERP system minimizes support. At most, a two-member team is required forgenerating reports and solving minor problems that surfaces up when a lot of varied datais in the database. This way a company could spend less on support and divert the moneyin purchasing new capabilities.
Choice of the databaseThe database should be meticulously chosen because a lot depends on it. It is the choiceof the database that determines the performance of the ERP system. Server database thatruns on a multi-user platform is required for an ERP application. Server databases containmechanisms that ensure reliability and consistency of data. The primary factor thatshould be looked for is the concurrency model. The two most commonly used serverdatabases are Microsoft SQL server and Oracle. Both have their own advantages anddisadvantages.
They differ widely in terms of the concurrency model. Oracle provides amulti version read consistency with no read locks and no dirty reads. Readers do notblock writers and writers do not block readers. In Microsoft SQL server, read consistencyis not available. It requires shared read locks to avoid dirty reads, if locks are not shared,dirty reads are possible. Also readers block writers and writers’ block readers. Deadlockscan be a serious issue with Microsoft SQL server, which escalates row-level locks, totable-level locks depending on the transaction’s volume.
To the user, the applicationsimply hangs. These unpleasant deadlock situations can result in aborting one or more ofthe concurrent users. Oracle, on the other hand, does not escalate row level locking.Microsoft SQL server is easier to use, easier to manage, less complex and requires lotless tuning than Oracle and is an excellent choice on windows platform. For crossplatform support, Oracle is an excellent choice, which runs very well both on windowsand Linux platforms.
Most ERP solutions are built on both these platforms, and it is up tothe customer to decide the database of their choice.ERP system securityPerhaps the most important module in an ERP application is the security module thatcreates logins and grants select, update, insert, delete, and execute etc rights to thevarious database objects such as tables and stored procedures. Most ERP solutionsrestrict user from directly accessing tables.
The user can perform operations on a table viaa stored procedure and these stored procedures have many validation checks for the data.Also, the idea is to pass the entire logic to back-end stored procedures so that debuggingand alterations become easy for the IT team. Another feature that should be looked for inthe security module is password encryption for the user logins. Password encryptionprevents direct access to the database servers thereby preventing malicious users fromgaining access to the servers. The user can only access the server through the ERPsoftware.
Transiting from an existing ERP system to a new oneThe new ERP provider should be able to migrate the existing ERP data to its new systemwith minimal effort, that is, by using data translators, scripts and useful programmingtechniques. The data should make sense in the new ERP system. Also the ERP providershould audit the data to ensure its integrity before making the system live. If the data isnot suitable for transfer, the ERP provider should perform initialization techniques likecalculating the opening balance amount for the new system, for inventory it can calculatethe opening stock for each of the items, etc.
Will the ERP provider support customization?This is a question frequently asked. It should be noted that no two business processes arealike. An ERP solution that suffices for a company may not be the be all and end allsolution for another company. At some point of time, customization is required. Thecustomization should also remain intact for future upgrades of the software. The factorthat should be looked upon is whether the ERP provider is capable of doing this.
TheERP solution should also have builder tools for creating new forms and report writertools for generating new reports. By having this, some customization can be done at theuser end also.
References
• “SAP ERP Upgrade: Management Strategies” by Larstan Business Reports
• “Technical Comparison of Oracle 9i Database vs. SQL Server 2000: Focus onPerformance” – An Oracle White Paper
Monday, November 20, 2006
Awal Mulanya...
Sekitar bulan april / may 2006, lupa, saya browsing internet, cari-cari peluang apa yang bisa dijual. Sebetulnya masih agak malas untuk mulai cari-cari usaha sampingan lagi. Apalagi belum lama sempat nggak untung dalam usaha penjualan software aplikasi handphone sms murah 10 perak via internet.
Searching kesana kemari, akhirnya nyangkut di blognya pak Roni Yuzirman. Disitu ada artikel tentang tawaran kios gratis untuk usaha di M2S dan di PGMTA. Wah.. kok enak banget ya.. sewa kios gratis di daerah elit pula. Gimana ya caranya supaya bisa dapat akses ke informasi seperti ini?
Karena ada milisnya (TDA, tangandiatas@yahoogroups.com), saya coba untuk subscribe disana. TDA adalah singkatan dari Tangan Di Atas. Artinya kurang lebih pengusaha kaya yang lebih suka memberi daripada menerima.
Ternyata artikel di blognya pak Roni serta isi email di milis sangat luar biasa. Artikel motivasi, sharing dari teman-teman yang beruntung memperoleh kios gratis, sharing dari teman-teman yang sudah mulai membuka usaha... Kenapa saya nggak ikut memulai?
Pertanyaan pertama, apa yang mau saya jual?
Pertanyaan ini lama berada di benak saya, sampai suatu saat saya membaca email sharing dari pak Hadi Kuntoro soal usahanya. Dari beberapa kali japri, saya tau apa yang dijual, dan yang membuat saya kaget adalah omzetnya. Edan... jualan jilbab ternyata bisa laku banget.
Saya coba datang langsung ke toko pak Hadi di bekasi, ternyata disana memang jilbabnya bagus-bagus. Rabbani. Saya baru lihat jilbab seperti itu. Dan beneran, wanita yang pakai kerudung itu jadi kelihatan lebih cantik dan modis. Nggak terkesan tertutup.
Setelah diskusi dengan istri, ok, kita putusin jual kerudung instant Rabbani, tapi bagaimana bisa dapat harga bagus? Bagaimana jalur distribusinya?
Dari searching di web, saya dapat no. telp dan email di bandung. Setelah komunikasi beberapa kali, saya dapat contact person agennya di bekasi berikut segala macam persyaratannya.
Sekarang, mau jualan dimana? Tempat belum ada, pegawai belum ada, saya dan istri juga masih berstatus karyawan dengan lokasi kantor yang cukup jauh dari rumah. Kantor saya di kawasan industri Delta Silicon Cikarang, sementara istri di kawasan industri Pulogadung. Dan rumah kami ada di cibubur.
Kami coba bicarakan hal ini dengan Ibu Mertua, karena memang beliau dulunya suka dagang, hanya saja setelah almarhum Bapak Mertua pensiun, beliau lebih aktif dalam kegiatan keagamaan.
Ternyata beliau bersedia membantu, ok, kita jualan dari garasi rumah mertua.
Sekitar pertengahan July 06, kita datangi Ibu Agen Rabbani di bekasi yang ternyata rumahnya luarbiasa jauh, kita ngobrol-ngobrol, setelah final, kita coba beli barangnya. Awalnya kita diminta belanja barang senilai Rp. 3 juta.
Rp. 3 juta.. jilbab semua, harus laku dalam sebulan, bisa nggak ya? Kalau nggak laku gimana? Kalau laku, berarti harus belanja lagi, padahal rumahnya jauh mana macet lagi... gimana ngaturnya? Pusing juga...
Tapi pokoknya Bismillah...
Selain dari garasi Ibu Mertua, kita coba titipkan barang di beberapa tempat. Istri sampai bela-belain cuti dari kantor untuk bergerilya ke berbagai sekolah muslim dan toko-toko untuk bisa titip barang. Seminggu berjalan ternyata hasilnya menggembirakan. Kita bisa belanja lagi, walaupun jauh.
Ini memicu kita untuk lebih serius memikirkan kelanjutan usaha ini. Kita mulai cari-cari lokasi usaha yang cocok di dekat-dekat rumah. Ternyata muahal-muahal ya yang namanya lokasi untuk usaha itu. Ada kios sederhana di pinggir jalan utama, minta 24 juta pertahun, dan dibayar untuk 2 tahun, 48 juta.. weleh... nggak sanggup.
Suatu malam, pulang kantor, istri mampir ke plaza cibubur, salah satu mall di wilayah cibubur yang lokasinya berada di seberang perumahan yang kami tempati. Sebelumnya saya sudah mencoba menghubungi pengelola tempat di plaza ini tapi kurang memperoleh respon positif.
Kebetulan dia secara tidak sengaja bisa langsung menemui EO pengelola tempat di lt. 3 dan diberitahu masih ada 1 kios kosong tapi lokasinya mentok di pojok, waduh.. Harga sewanya sih masih masuk budget dan yang paling enak adalah bisa dibayar bulanan... sip.. sip.. ambil aja deh. Soal lokasi, ya gimana lagi.. yang penting masuk dulu walau hati kecil sebetulnya agak ragu, tapi semangat dari istri bisa sedikit menular, sedikit lho.
Yang bikin deg-degan, kita cuma dikasih waktu sekitar 10 hari untuk buka kios. Belakangan, ternyata ada salah seorang yang sudah booking kios di lokasi yang lebih baik ternyata mengundurkan diri, jadilah kiosnya kita ambil.
Grabak grubuk... beli peralatan toko di tanah abang (ternyata harga disana ga lebih murah), gotong-gotong kepala manekin untuk display jilbab, gawang untuk gantungan baju, ram kawat untuk gantungan jilbab, berat euy... Panggil tukang langganan utk perbaiki dekorasi interior kios. Interior dikerjakan malam hari, setelah mall tutup, sampai menjelang dini hari selama beberapa malam.
Oiya, nanti yang mau jualan siapa? Orangnya jujur apa nggak? Gajinya berapa? Berapa orang yang mau jaga? Jam kerjanya bagaimana? Bagaimana caranya supaya dia mau bekerja dengan baik, bisa menawarkan barang? Aduh.. masih banyak pertanyaan. Kalau sudah begini bawaannya ingin ngomel melulu, stress...
Finally, hari sabtu tanggal 5 agustus 2006, menjadi hari yang bersejarah. Setelah 16 tahun saya dan istri kerja kantoran, pagi itu kita berdua (eh bertiga dink sama si kecil Nadya) sukses berdiri menjadi penjaga toko, hehehe...
Ruzika Collection
Plaza Cibubur lt. 3 (atas KFC)
Jl. Raya Alternatif Cibubur Cilengsi.
Searching kesana kemari, akhirnya nyangkut di blognya pak Roni Yuzirman. Disitu ada artikel tentang tawaran kios gratis untuk usaha di M2S dan di PGMTA. Wah.. kok enak banget ya.. sewa kios gratis di daerah elit pula. Gimana ya caranya supaya bisa dapat akses ke informasi seperti ini?
Karena ada milisnya (TDA, tangandiatas@yahoogroups.com), saya coba untuk subscribe disana. TDA adalah singkatan dari Tangan Di Atas. Artinya kurang lebih pengusaha kaya yang lebih suka memberi daripada menerima.
Ternyata artikel di blognya pak Roni serta isi email di milis sangat luar biasa. Artikel motivasi, sharing dari teman-teman yang beruntung memperoleh kios gratis, sharing dari teman-teman yang sudah mulai membuka usaha... Kenapa saya nggak ikut memulai?
Pertanyaan pertama, apa yang mau saya jual?
Pertanyaan ini lama berada di benak saya, sampai suatu saat saya membaca email sharing dari pak Hadi Kuntoro soal usahanya. Dari beberapa kali japri, saya tau apa yang dijual, dan yang membuat saya kaget adalah omzetnya. Edan... jualan jilbab ternyata bisa laku banget.
Saya coba datang langsung ke toko pak Hadi di bekasi, ternyata disana memang jilbabnya bagus-bagus. Rabbani. Saya baru lihat jilbab seperti itu. Dan beneran, wanita yang pakai kerudung itu jadi kelihatan lebih cantik dan modis. Nggak terkesan tertutup.
Setelah diskusi dengan istri, ok, kita putusin jual kerudung instant Rabbani, tapi bagaimana bisa dapat harga bagus? Bagaimana jalur distribusinya?
Dari searching di web, saya dapat no. telp dan email di bandung. Setelah komunikasi beberapa kali, saya dapat contact person agennya di bekasi berikut segala macam persyaratannya.
Sekarang, mau jualan dimana? Tempat belum ada, pegawai belum ada, saya dan istri juga masih berstatus karyawan dengan lokasi kantor yang cukup jauh dari rumah. Kantor saya di kawasan industri Delta Silicon Cikarang, sementara istri di kawasan industri Pulogadung. Dan rumah kami ada di cibubur.
Kami coba bicarakan hal ini dengan Ibu Mertua, karena memang beliau dulunya suka dagang, hanya saja setelah almarhum Bapak Mertua pensiun, beliau lebih aktif dalam kegiatan keagamaan.
Ternyata beliau bersedia membantu, ok, kita jualan dari garasi rumah mertua.
Sekitar pertengahan July 06, kita datangi Ibu Agen Rabbani di bekasi yang ternyata rumahnya luarbiasa jauh, kita ngobrol-ngobrol, setelah final, kita coba beli barangnya. Awalnya kita diminta belanja barang senilai Rp. 3 juta.
Rp. 3 juta.. jilbab semua, harus laku dalam sebulan, bisa nggak ya? Kalau nggak laku gimana? Kalau laku, berarti harus belanja lagi, padahal rumahnya jauh mana macet lagi... gimana ngaturnya? Pusing juga...
Tapi pokoknya Bismillah...
Selain dari garasi Ibu Mertua, kita coba titipkan barang di beberapa tempat. Istri sampai bela-belain cuti dari kantor untuk bergerilya ke berbagai sekolah muslim dan toko-toko untuk bisa titip barang. Seminggu berjalan ternyata hasilnya menggembirakan. Kita bisa belanja lagi, walaupun jauh.
Ini memicu kita untuk lebih serius memikirkan kelanjutan usaha ini. Kita mulai cari-cari lokasi usaha yang cocok di dekat-dekat rumah. Ternyata muahal-muahal ya yang namanya lokasi untuk usaha itu. Ada kios sederhana di pinggir jalan utama, minta 24 juta pertahun, dan dibayar untuk 2 tahun, 48 juta.. weleh... nggak sanggup.
Suatu malam, pulang kantor, istri mampir ke plaza cibubur, salah satu mall di wilayah cibubur yang lokasinya berada di seberang perumahan yang kami tempati. Sebelumnya saya sudah mencoba menghubungi pengelola tempat di plaza ini tapi kurang memperoleh respon positif.
Kebetulan dia secara tidak sengaja bisa langsung menemui EO pengelola tempat di lt. 3 dan diberitahu masih ada 1 kios kosong tapi lokasinya mentok di pojok, waduh.. Harga sewanya sih masih masuk budget dan yang paling enak adalah bisa dibayar bulanan... sip.. sip.. ambil aja deh. Soal lokasi, ya gimana lagi.. yang penting masuk dulu walau hati kecil sebetulnya agak ragu, tapi semangat dari istri bisa sedikit menular, sedikit lho.
Yang bikin deg-degan, kita cuma dikasih waktu sekitar 10 hari untuk buka kios. Belakangan, ternyata ada salah seorang yang sudah booking kios di lokasi yang lebih baik ternyata mengundurkan diri, jadilah kiosnya kita ambil.
Grabak grubuk... beli peralatan toko di tanah abang (ternyata harga disana ga lebih murah), gotong-gotong kepala manekin untuk display jilbab, gawang untuk gantungan baju, ram kawat untuk gantungan jilbab, berat euy... Panggil tukang langganan utk perbaiki dekorasi interior kios. Interior dikerjakan malam hari, setelah mall tutup, sampai menjelang dini hari selama beberapa malam.
Oiya, nanti yang mau jualan siapa? Orangnya jujur apa nggak? Gajinya berapa? Berapa orang yang mau jaga? Jam kerjanya bagaimana? Bagaimana caranya supaya dia mau bekerja dengan baik, bisa menawarkan barang? Aduh.. masih banyak pertanyaan. Kalau sudah begini bawaannya ingin ngomel melulu, stress...
Finally, hari sabtu tanggal 5 agustus 2006, menjadi hari yang bersejarah. Setelah 16 tahun saya dan istri kerja kantoran, pagi itu kita berdua (eh bertiga dink sama si kecil Nadya) sukses berdiri menjadi penjaga toko, hehehe...
Ruzika Collection
Plaza Cibubur lt. 3 (atas KFC)
Jl. Raya Alternatif Cibubur Cilengsi.
Subscribe to:
Posts (Atom)