Last September, we posted in our website a rather vague product page on wave generators for swimming pools. The product here is the Wave Ball, an innovative wave generator in the form of a ball that works through the principle of resonance.
The wave ball is an energy saving alternative to traditional brute-force powerful wave generators. The wave ball is an engineering feat, devised through expert knowledge of wave behaviour, computer technology, and precise manufacturing. Its energy saving feature is due to "reuse" and adaptation of reflected waves within the swimming pool to create desired waves up to 1 meter high.
Yesterday, after nearly six months since initial posting and information gathering, we have formally introduced the Wave Ball to our sales force. Due to its rather expensive initial costs, it is a special niche product. However, we believe it has tremendous potential through huge operational savings.
Wednesday, March 10, 2010
Wednesday, March 3, 2010
Service Desk Soft Start
A month ago, I talked about an information systems module for our service department. Since then, Amici's IT and Service department have held a few meetings on expectations and mock ups of the module, not surprisingly called Service Desk.
Service Desk was designed after our company's short-lived experiments with Request Tracker and OTRS, both open source web-based issue trackers. We did not push through with web-based issue trackers because we needed a customized system well integrated with our current stack. We were not looking for a help desk system, but instead a service and schedule management system. OTRS felt too IT-ish, which our company is not. Request Tracker lasted longer (two weeks) but lack of integration to our CRM proved cumbersome.
That was two years ago. Service Desk collected dust instead of improving our service because the process to interface with it, the overall structure of our Service Department was only to be stabilized two years after.
Last Saturday, we formally introduced Service Desk to our sales force. Rather than the original rudimentary table design that stressed outstanding service requests, it sported a new employee daily schedule interface that gives focus on scheduling constraints and resource management. The table design is still available as an alternative view, but for the main target users, our service managers and our sales team, the daily schedule view remains the obvious choice.
Sales brought up an obvious request. Should not Sales be allowed to create the service requests themselves? Then, our service managers need only to monitor outstanding requests so that they can schedule them appropriately.
This option is readily available, should service request processes be revised. In fact, this was the original design of the Service Desk. However, it remains to be seen whether the size of our company shall warrant the process change.
Right now, when Sales request services, they usually call any one of three service managers to relay details and wait for an SR number. Sometimes, it's easier to jot down details on a small sheet of paper and to hand that personally to our service managers. Unfortunately, in practice a lot of waiting may have to be done either way. Jotting down details on paper also duplicates encoding of the service request.
The proponents of the separation of duties for Service Requests and Job Orders espouses the advantages of the analogous Sale Order and Sale Invoice system.
The requestors will themselves encode their requests, reducing the encoding bottleneck by a factor up to 7 (20+ people to encode their own requests, rather than 3 to encode everyone's requests), and also reduce typical errors such as misspellings. A standard work flow for requesting service is simply clicking on a Service button from the related Sale Invoice to automatically fill up fields and link the sale to the service request. Service Managers can then focus on providing appropriate schedules for all outstanding requests.
The communication pattern between requestors and service managers will be different. Instead of the current poll-waiting method whereby Sales busily waits for an available Service Manager to communicate his requests, a message passing, event-driven methodology becomes natural. This is akin to email instead of the telephone.
Requestors will not have to wait for an SR number. The computer system automatically provides a request ID and even notifies requestors via email any updates on their requests. Service Managers will be notified of any pending requests and are free to schedule them. Scheduling those requests in turn automatically notifies requestors of the new schedules.
I believe the SR <> JO system is appropriate especially for big companies. The poll waiting communication pattern is obviously inefficient for large volume of issue/service tickets. For our company however, our lower volume might not give enough points to either methodologies.
Service Desk was designed after our company's short-lived experiments with Request Tracker and OTRS, both open source web-based issue trackers. We did not push through with web-based issue trackers because we needed a customized system well integrated with our current stack. We were not looking for a help desk system, but instead a service and schedule management system. OTRS felt too IT-ish, which our company is not. Request Tracker lasted longer (two weeks) but lack of integration to our CRM proved cumbersome.
That was two years ago. Service Desk collected dust instead of improving our service because the process to interface with it, the overall structure of our Service Department was only to be stabilized two years after.
Last Saturday, we formally introduced Service Desk to our sales force. Rather than the original rudimentary table design that stressed outstanding service requests, it sported a new employee daily schedule interface that gives focus on scheduling constraints and resource management. The table design is still available as an alternative view, but for the main target users, our service managers and our sales team, the daily schedule view remains the obvious choice.
Sales brought up an obvious request. Should not Sales be allowed to create the service requests themselves? Then, our service managers need only to monitor outstanding requests so that they can schedule them appropriately.
This option is readily available, should service request processes be revised. In fact, this was the original design of the Service Desk. However, it remains to be seen whether the size of our company shall warrant the process change.
Right now, when Sales request services, they usually call any one of three service managers to relay details and wait for an SR number. Sometimes, it's easier to jot down details on a small sheet of paper and to hand that personally to our service managers. Unfortunately, in practice a lot of waiting may have to be done either way. Jotting down details on paper also duplicates encoding of the service request.
The proponents of the separation of duties for Service Requests and Job Orders espouses the advantages of the analogous Sale Order and Sale Invoice system.
The requestors will themselves encode their requests, reducing the encoding bottleneck by a factor up to 7 (20+ people to encode their own requests, rather than 3 to encode everyone's requests), and also reduce typical errors such as misspellings. A standard work flow for requesting service is simply clicking on a Service button from the related Sale Invoice to automatically fill up fields and link the sale to the service request. Service Managers can then focus on providing appropriate schedules for all outstanding requests.
The communication pattern between requestors and service managers will be different. Instead of the current poll-waiting method whereby Sales busily waits for an available Service Manager to communicate his requests, a message passing, event-driven methodology becomes natural. This is akin to email instead of the telephone.
Requestors will not have to wait for an SR number. The computer system automatically provides a request ID and even notifies requestors via email any updates on their requests. Service Managers will be notified of any pending requests and are free to schedule them. Scheduling those requests in turn automatically notifies requestors of the new schedules.
I believe the SR <> JO system is appropriate especially for big companies. The poll waiting communication pattern is obviously inefficient for large volume of issue/service tickets. For our company however, our lower volume might not give enough points to either methodologies.
Tuesday, February 16, 2010
IT and You
As a small company in growing pains, Amici has grown accustomed to incessant process changes in constant search for the best way of doing things. Some changes though not merely whims without reasons are due perhaps to hypotheses and not so scientific methods of experimentations. Most will have foundations in text book analyses and prescriptions of friends in or out of the industry. It should be good then that we are not so big as to be inflexible. We strive to be agile.
Information technology is one pillar our company leans on to improve itself. And as much as changes live and die and evolve through generations, information technology only outlives itself due to constant makeover. Processes such as counting inventory, tracking serial numbers, monitoring expenses, preparing our next orders, etc. find themselves renovated as ideas and plans come into fruition in every next iteration of our information system.
People, whether cooperative or antagonistic towards each and every change, play the bigger part in moulding our company evolution. IT changes that find huge backlashes are commonly flawed in design or expectations. People are the users who swear by the strengths of and curse the weaknesses of our system. They demand change more demandingly than mere routine pro-activeness.
There is however a natural wall between people and IT. On one side, a lot of people do not know what to seek from IT. They live with what's there, and dismiss inefficiencies as way of life. And then on the other side are people who see IT too magically, without practical consideration to time or budget. IT though materially inexpensive costs time and manpower.
Also, the software developer who receives requests from users is too often distanced to understand what users expect. Users themselves do not know too well their requirements, and the software developer challenged in communication is only happy to guess usage and expectations.
The solution of course is a comfortable entanglement between IT and users. But before that, Amici IT should seek organization and sustainability.
Information technology is one pillar our company leans on to improve itself. And as much as changes live and die and evolve through generations, information technology only outlives itself due to constant makeover. Processes such as counting inventory, tracking serial numbers, monitoring expenses, preparing our next orders, etc. find themselves renovated as ideas and plans come into fruition in every next iteration of our information system.
People, whether cooperative or antagonistic towards each and every change, play the bigger part in moulding our company evolution. IT changes that find huge backlashes are commonly flawed in design or expectations. People are the users who swear by the strengths of and curse the weaknesses of our system. They demand change more demandingly than mere routine pro-activeness.
There is however a natural wall between people and IT. On one side, a lot of people do not know what to seek from IT. They live with what's there, and dismiss inefficiencies as way of life. And then on the other side are people who see IT too magically, without practical consideration to time or budget. IT though materially inexpensive costs time and manpower.
Also, the software developer who receives requests from users is too often distanced to understand what users expect. Users themselves do not know too well their requirements, and the software developer challenged in communication is only happy to guess usage and expectations.
The solution of course is a comfortable entanglement between IT and users. But before that, Amici IT should seek organization and sustainability.
Sunday, January 31, 2010
Number Business
Like any normal business, we work with numbers here in Amici Water Systems. Sales agents compute discounts and totals for each of their sales; the collector or cashier computes change for the customers; sales supervisors add up her group's sales for the quarter and their expenses; HR handles the intricate payroll in a very complicated spreadsheet in OpenOffice.org; marketing does forecasts for her latest marketing project; service and project managers work with limited sets of resources and time to prepare service estimates and project schedules; managers and accountants look at financial statements.
Unlike a lot of businesses however, our major products are heavily about numbers. When we size water heaters for your home, swimming pool, or a hotel, we may need basic numbers like the number and flow capacities of showers, the number of bathtubs, the dimension of your pool and the ambient temperature of water and atmosphere, or the number of rooms in a hotel or occupancy rate during peak hours for water heating. The number of solar panels needed, the output capacity of heat pump water heaters, the storage capacity of hot water tanks form a system to provide enough hot water at a desired temperature for however your business uses hot water. Pumps and tanks are sized according to required volume and pressure as well as horizontal and vertical distances between water source and installation site. The appropriate models of swimming pool pumps and filters for your swimming pool depend on the volume of your swimming pool as well as its usage. Our products are technical. They are a number business.
Due to the nature of our business, it is important for our people to know their math, and do it well. Though our various product trainings cover to a degree specific product physics informally, there is so much room for improvement in our technical training program. Formalization of the program, including gradation and tests, will be helpful in the long run in educating our people.
Arming our people with efficient tools are just as important. While the old-fashioned basic calculator is still the preferred equipment of many, due to its convenience and portability, the versatile spreadsheet and other computer programs are available for more advanced computations. Our product catalog has a few pages devoted to conversion tables. We have a compilation of spreadsheet/form templates for various common calculations in our day to day business to speed response time. At one point, I've even written a small unit conversion tool to help convert basic units of measurement we use in our company. Nowadays, with internet access being almost a given, Google's built in calculator has been a boon to quick and easy calculations.
My personal favorite calculator, however, is Qalculate. Unfortunately for Windows and Mac users, it is only available under Linux. (Fortunately for our company, we use Ubuntu, a fairly easy-to-use Linux distribution, in which installing Qalculate is just a search and a few clicks away.) Qalculate not only features a robust scientific mode but also unit conversions, currency conversions, and even calculus. As an example of its power, you can enter 6 kilowatt hour to Btu and it gives you 20.472747 kBtu. Computing the desired gpm pump requirement for a residential swimming pool 10 meters long, 6 meters wide, and 5 feet deep is simply entering the following expression:
10 meters * 6 meters * 5 feet / 8 hours to gal/min
It gives an answer ~ 50.324776 gal / min.
Unlike a lot of businesses however, our major products are heavily about numbers. When we size water heaters for your home, swimming pool, or a hotel, we may need basic numbers like the number and flow capacities of showers, the number of bathtubs, the dimension of your pool and the ambient temperature of water and atmosphere, or the number of rooms in a hotel or occupancy rate during peak hours for water heating. The number of solar panels needed, the output capacity of heat pump water heaters, the storage capacity of hot water tanks form a system to provide enough hot water at a desired temperature for however your business uses hot water. Pumps and tanks are sized according to required volume and pressure as well as horizontal and vertical distances between water source and installation site. The appropriate models of swimming pool pumps and filters for your swimming pool depend on the volume of your swimming pool as well as its usage. Our products are technical. They are a number business.
Due to the nature of our business, it is important for our people to know their math, and do it well. Though our various product trainings cover to a degree specific product physics informally, there is so much room for improvement in our technical training program. Formalization of the program, including gradation and tests, will be helpful in the long run in educating our people.
Arming our people with efficient tools are just as important. While the old-fashioned basic calculator is still the preferred equipment of many, due to its convenience and portability, the versatile spreadsheet and other computer programs are available for more advanced computations. Our product catalog has a few pages devoted to conversion tables. We have a compilation of spreadsheet/form templates for various common calculations in our day to day business to speed response time. At one point, I've even written a small unit conversion tool to help convert basic units of measurement we use in our company. Nowadays, with internet access being almost a given, Google's built in calculator has been a boon to quick and easy calculations.
My personal favorite calculator, however, is Qalculate. Unfortunately for Windows and Mac users, it is only available under Linux. (Fortunately for our company, we use Ubuntu, a fairly easy-to-use Linux distribution, in which installing Qalculate is just a search and a few clicks away.) Qalculate not only features a robust scientific mode but also unit conversions, currency conversions, and even calculus. As an example of its power, you can enter 6 kilowatt hour to Btu and it gives you 20.472747 kBtu. Computing the desired gpm pump requirement for a residential swimming pool 10 meters long, 6 meters wide, and 5 feet deep is simply entering the following expression:
10 meters * 6 meters * 5 feet / 8 hours to gal/min
It gives an answer ~ 50.324776 gal / min.
Saturday, January 30, 2010
Traditions
Our company as organizations do grows its traditions with age. Though our company history is more than 30 years already, more than half the average lifespan of a corporation, our company in its current form is very young.
The first five years have been about products. With a small office for three people, our company grew slowly but steadily, selling good products at fair prices while maintaining low overhead. Tradition has been opening at day and closing at night, and the year-end inventory.
The next years after up to now however have brought dramatic changes. Leadership developed and luck blessed our company. Now, it's really about the people, good people, selling good products. More social traditions followed.
Some of our major company events such as Christmas parties and Team-building are recent traditions. They do not make much sense in a company of 3 or 4 persons.
Some haven't earned their keep to be called traditions. This new year's company outlook missed this year (Or I missed it somehow.) Last year's sportsfest and moon cake festival were unceremoniously aborted after typhoon Ondoy. Nevertheless, this year holds promise for the sportsfest's continuation with an already scheduled chess tournament.
These recent company traditions arose from normal progressions of relationships. As our company focused on people, relationships among develop to form cohesive groupings. Working with more people preludes socializing with more people. When there's stability, social interaction in and out of office contribute to each other's growth and group cohesiveness. Lack of maintenance on the other hand brings about apathy and division.
It would have been lacklustre if traditions were to arise only for its own, as a pure business decision without magic of innovation and communication, with a goal first and foremost to promote bonding as if it can be plasticized so conveniently. (But one can still grow from there, giving probably adaptation and creativity.)
Our sportsfest (or the idea of) have been borne in part from common sports played by fellow officemates. Our weekly basketball have been quite steady for the past year. Badminton, though it hasn't caught on, has fans such as yours truly. Chess? Table tennis? People among are finding common grounds of activities, on which to share and find unity.
As an young, agile company, we can expect traditions to come to show the Amici way. More people coming in means more possibilities of formation. When people go out, we expect changes. We must be alive to maintain the best traditions and let bad traditions die quietly.
The first five years have been about products. With a small office for three people, our company grew slowly but steadily, selling good products at fair prices while maintaining low overhead. Tradition has been opening at day and closing at night, and the year-end inventory.
The next years after up to now however have brought dramatic changes. Leadership developed and luck blessed our company. Now, it's really about the people, good people, selling good products. More social traditions followed.
Some of our major company events such as Christmas parties and Team-building are recent traditions. They do not make much sense in a company of 3 or 4 persons.
Some haven't earned their keep to be called traditions. This new year's company outlook missed this year (Or I missed it somehow.) Last year's sportsfest and moon cake festival were unceremoniously aborted after typhoon Ondoy. Nevertheless, this year holds promise for the sportsfest's continuation with an already scheduled chess tournament.
These recent company traditions arose from normal progressions of relationships. As our company focused on people, relationships among develop to form cohesive groupings. Working with more people preludes socializing with more people. When there's stability, social interaction in and out of office contribute to each other's growth and group cohesiveness. Lack of maintenance on the other hand brings about apathy and division.
It would have been lacklustre if traditions were to arise only for its own, as a pure business decision without magic of innovation and communication, with a goal first and foremost to promote bonding as if it can be plasticized so conveniently. (But one can still grow from there, giving probably adaptation and creativity.)
Our sportsfest (or the idea of) have been borne in part from common sports played by fellow officemates. Our weekly basketball have been quite steady for the past year. Badminton, though it hasn't caught on, has fans such as yours truly. Chess? Table tennis? People among are finding common grounds of activities, on which to share and find unity.
As an young, agile company, we can expect traditions to come to show the Amici way. More people coming in means more possibilities of formation. When people go out, we expect changes. We must be alive to maintain the best traditions and let bad traditions die quietly.
Wednesday, January 20, 2010
Service Now Next Door
Along the restructuring of our service group this early came well thought plans, wishful experiments and wide-eyed thinking. Within a few days from conception, we now have service request forms printed in triplicate, serialized, carbonized, glued, and in archaic colors. Our service team has left the cramped office for a more spacious room. They got some local phones sometimes working and then some. Internet connection and wiring was assisted by yours truly. And just today, they have another computer to play with!
The service request forms serve to put in writing whatever service is tasked to do. And by that, I mean anything. It actually surprised me the first couple of times I saw some non-operational tasks put in the service forms. The service request forms (which I secretly call Job Order forms (because that's what I called them back in July last year in its computerized version)) are creatively colored white, pink, and yellow. Not. They're also conveniently segregated into two series: A and B. I'm not sure which service group is A and which is B, but I'm pretty sure the service group has that written somewhere. Last week, I was trying to encode some of the forms in the computer. Unfortunately I encountered quite a number of cacographical issues.
I think they'll have to have some kind of filing cabinets sooner or later. Although from what I see with the implementation so far, you wouldn't want to browse through them just to look for one particular form. Thinking about filing so much data makes me want to study library science some time.
The service team has finally left our office, to the rightful dismay of office mates who habitually answer the phones. One thing that made service a bit problematic was that it can be hard to get in touch with them. Sometimes, you can't get one complete sentence from them without some preemptive phone call to distract them. Although the communication issue is with much merit, the space problem is just as big an issue. We have now three guys (1.4 + .75 + .85 = 3) sharing one chair, one table, one computer and half a phone. When they get visitors (and they get lots of them), it can be crowded. So moving them out sort of won that one. At least temporarily. I think the communication issue can be fixed in more creative ways.
Which is why they now have two local numbers. Three would have been better. But right now, the two are not yet perfectly working. So let's work that out first. It would have been fantastic if they can have a sort of local trunk number which our main office can dial to ring any available phone on their side. That is certainly plausible if I can convince management to invest in an Asterisk server to replace our dinosaur of a PABX. Other options include video intercom and instant messaging.
What happens if you've got 3 computer novices in an air conditioned room, well hidden from prying eyes, and two computers with internet? Chess death match anyone? Well not really. They haven't gone that far except for the nearly ubiquitous Facebook. Now one is helping the other how to do some Empathy, while having fun with Cheese. Then there's the question of how to shut down.
The service request forms serve to put in writing whatever service is tasked to do. And by that, I mean anything. It actually surprised me the first couple of times I saw some non-operational tasks put in the service forms. The service request forms (which I secretly call Job Order forms (because that's what I called them back in July last year in its computerized version)) are creatively colored white, pink, and yellow. Not. They're also conveniently segregated into two series: A and B. I'm not sure which service group is A and which is B, but I'm pretty sure the service group has that written somewhere. Last week, I was trying to encode some of the forms in the computer. Unfortunately I encountered quite a number of cacographical issues.
I think they'll have to have some kind of filing cabinets sooner or later. Although from what I see with the implementation so far, you wouldn't want to browse through them just to look for one particular form. Thinking about filing so much data makes me want to study library science some time.
The service team has finally left our office, to the rightful dismay of office mates who habitually answer the phones. One thing that made service a bit problematic was that it can be hard to get in touch with them. Sometimes, you can't get one complete sentence from them without some preemptive phone call to distract them. Although the communication issue is with much merit, the space problem is just as big an issue. We have now three guys (1.4 + .75 + .85 = 3) sharing one chair, one table, one computer and half a phone. When they get visitors (and they get lots of them), it can be crowded. So moving them out sort of won that one. At least temporarily. I think the communication issue can be fixed in more creative ways.
Which is why they now have two local numbers. Three would have been better. But right now, the two are not yet perfectly working. So let's work that out first. It would have been fantastic if they can have a sort of local trunk number which our main office can dial to ring any available phone on their side. That is certainly plausible if I can convince management to invest in an Asterisk server to replace our dinosaur of a PABX. Other options include video intercom and instant messaging.
What happens if you've got 3 computer novices in an air conditioned room, well hidden from prying eyes, and two computers with internet? Chess death match anyone? Well not really. They haven't gone that far except for the nearly ubiquitous Facebook. Now one is helping the other how to do some Empathy, while having fun with Cheese. Then there's the question of how to shut down.
Saturday, January 9, 2010
Service Revamp
This morning held a much awaited sales-service meet. I would say much awaited as I've been expecting a major restructuring of service for a while now. Our company has met much difficulties the past couple of years, ballooning in expenses and manpower, as well as service requests and back orders. We've gone through several persons each doing his or her best to take on the daunting role of the service manager. There were high expectations to be met. Some have gone their separate ways. Some have shifted to roles a bit less challenging. And then some have persevered through thick and thin, goals met or unmet. We've added people with different levels of training. But after the past year, we still aren't there. We're in much need of foundational and procedural improvements.
Unfortunately, I wasn't able to join in much of the meeting. Actually, I might have missed the session completely if not for perky ears on an early curious morning. I did my best to attend, even if I felt somewhat uninvited, although I skipped the delicious breakfast of tuyo and salted eggs -- dietary compulsions. Alas, with other important things to attend, it seems I only got to the intro and finale. It might have been exponentially interesting to get to the gist of the meeting.
What can we expect? From what I see, there will be papers and more, and trees crying. Service order forms, return forms, differentiation of repair and delivery/installations -- seems standard fare in traditional companies. They will do much good in making our service operations measurable -- as long as they're properly implemented. Splitting the service group to Repairs and Delivery/Installation can help in response times and specializations. Ultimately it will be about customer satisfaction. Expect things to become much much better.
~~~
As a side note, it seems I can't say much given how out of the loop I sometimes feel now about various company processes. As I'm more of an IT and Supply Chain personnel, I'm still trying to see how the changes will fit in the overall scheme. On one end, it's disheartening not to have input about the changes being implemented. I've already wrote a service module in our in-house enterprise system, though it needed more love and attention, and actual use and tuning. (I'm all for evolutionary programming, although right now I'm by myself.) On the other end, I'm still excited to work on redesigning the service management module. The past month, I've been contemplating on getting more hands-on service management experience. There are naysayers on implementing it through computers, valid reasons all -- personnel "computational complexity", keeping things simple, etc. But I don't really see the conflict. It's a design problem. That's the exciting part.
Unfortunately, I wasn't able to join in much of the meeting. Actually, I might have missed the session completely if not for perky ears on an early curious morning. I did my best to attend, even if I felt somewhat uninvited, although I skipped the delicious breakfast of tuyo and salted eggs -- dietary compulsions. Alas, with other important things to attend, it seems I only got to the intro and finale. It might have been exponentially interesting to get to the gist of the meeting.
What can we expect? From what I see, there will be papers and more, and trees crying. Service order forms, return forms, differentiation of repair and delivery/installations -- seems standard fare in traditional companies. They will do much good in making our service operations measurable -- as long as they're properly implemented. Splitting the service group to Repairs and Delivery/Installation can help in response times and specializations. Ultimately it will be about customer satisfaction. Expect things to become much much better.
~~~
As a side note, it seems I can't say much given how out of the loop I sometimes feel now about various company processes. As I'm more of an IT and Supply Chain personnel, I'm still trying to see how the changes will fit in the overall scheme. On one end, it's disheartening not to have input about the changes being implemented. I've already wrote a service module in our in-house enterprise system, though it needed more love and attention, and actual use and tuning. (I'm all for evolutionary programming, although right now I'm by myself.) On the other end, I'm still excited to work on redesigning the service management module. The past month, I've been contemplating on getting more hands-on service management experience. There are naysayers on implementing it through computers, valid reasons all -- personnel "computational complexity", keeping things simple, etc. But I don't really see the conflict. It's a design problem. That's the exciting part.
Subscribe to:
Posts (Atom)
Posts
