← Back to team overview

gourmet team mailing list archive

New team member :-)

 

Hello everybody!

Thanks for accepting me into the team, Bernhard!

Just to introduce myself briefly; my name is Harald Franzen, originally Dutch but I run a small business in France. This business provides services to cave divers that visit this remote region in France where I live, and the services we offer include lodging, filling scuba tanks for diving and a restaurant (and a few things around it). In essence, I am a provider of logistical services for people that visit this region to go diving.

This winter -a relatively "slow" period of the year- I was looking to improve my logistics around the purchasing of food, and I set out to write a database with recipes, so I could quickly create shopping lists for the food we need to purchase. At a certain point I had the luminous idea :-) to see if somebody hadn't already invented the wheel. And indeed, the wheel had been invented by Thomas Hinkle and the wheel seemed to be round too!

Thanks guys for an excellent job! You have made my life a bit easier and that's fantastic!

When I started playing around with Gourmet, I ran into some issues (that are particular to my setup) and hence I got in touch with Bernhard who kindly invited me into the team.

It may be useful to know that in my "previous life" I used to be a management consultant, specialised in business process improvement and as such worked on roughly 15 ERP implementations for various medium European companies. I am not a software specialist, but I do understand processes and their translation into concepts that software specialists then transform into working code.

I have -with the aid of Bernhard- already forked Gourmet to work on the Dutch translation - I noticed some issues there, but I also have a Use Case to present, as preparing food on a scale inbetween the average houshold and a big restaurant is part of what we do here in France. I have pasted that Use Case below, for your information. Maybe some of the things I find within the inner workings of Gourmet entice you to develop software for it. I do fully understand that some of my requests/wishes are really a big ask, so do not worry about that: I will work with whatever is available :-)

Also, I do apologize beforehand, because obviously -apart from a yet limited user experience- I know little to nothing about Gourmet and the way you have chosen to translate functionality into workable code, database structures, and so on. So whenever I write something really stupid, please forgive me!

Best regards and looking forward!


Harald

---------------------------------------------------------
Gourmet Use Case

Small restaurant, serving on average roughly 3 guests per night al year, totalling around 1200 servings per year, consisting of breakfast, a packed lunch (guests will leave the premises during the day) and a dinner comprised of starter, main course (including side dishes) and a dessert.

Effectively, as the restaurant is part of a seasonal business (cave diving center hosting and providing to cave divers three main services: lodging, filling of diving bottles and food), the occupancy is around 5-6 "in season", peaking to 12-16 guests at peak moments. Scalability in purchasing is important, as the turn-over rate is almost instantaneous (3-4 days cycle during "slower" times, 2 days during "busy" times). Storage space is limited and product freshness paramount.

Shopping logistics are difficult: the business is located in a remote area and the nearest bigger supermarket is 35 minutes driving away. Also, all operations are catered for by two people, so efficiency and effectivity are very important -- any ingredient not purchased at the right time means an extra shopping trip, incurring losses in time and money (because of the extra driving).

The restaurant is not allowed -due to legal restraints- to offer a menu, unless guests have particular dietary requirements (vegetarien, food allergies and so on). That is to say that the composition of dinner -and thus the ingredients and quantities thereof- is determined by the restaurant, not by the guests.

The pool of recipes includes all types of dishes (soups, starters, fish courses, meat courses, all desserts, etcetera, etcetera), contains roughly 200 recipes, varying from classical French dishes to Asian, African and North American foods. Typically, the restaurant will cycle through different regions of origins and create an alternation of the staple food (so rice one evening, pasta the next, potatoes after that, and so on) and an alternation of the character of the dishes (so not different stews evening after evening, for example).

Next to planning and executing dinners, the restaurant uses a list of ingredients that will need replenishing from time to time (for breakfast and lunches, mainly; or stock items for general use -- like ground coffee, salt, (olive) oil, and so on).

Each winter (low season), the current "book of recipes" is reviewed and some recipes will become obsolete whilst new recipes will be added in a bid to improve quality, reduce cost and renew the offer especially for those guests that return frequently (2 -- 3 times a year).

Next to purchasing efficiency, efficiency in quantities (reducing or preferably iliminating waste) is an important goal. The restaurant aims at a 700 gram dinner each evening, providing quality and healthy food for physically active guests. The aim to reduce waste has not only an ethical, but also a financial background.

In order to achieve quality food at low cost, all meals are prepared "from scratch", using fresh ingredients where possible and avoiding pre-processed foods where ever possible. This is the chosen method to add as much value as possible.

The restaurant seeks to more efficiently and effectively create shopping lists, automatically scaling for varying occupancy, reducing time to generate the shopping list from the proposed/planned meals and avoiding errors in copying ingredients' lists (currently an activity that is done manually).

1. Ideally, conversions of ingredients' units should be "perfect" (currently, a shopping list might read "sugar: 100 g + ½ tablespoon + 1 teaspoon") and on the shoppings lists should emerge in "units of purchase" (currently this feature does not exist in Gourmet).

2. A quantitative "larder" function (so stock keeping functionality) should be available (the current "larder-functionality" in Gourmet already offers some functionality to assist in eliminating ingredients that are already on stock, however, this is a manual operation).

3. Order points could be added and purchase of (almost) out-of-stock items suggested, by enabling reduction of the larder once the user indicates a certain menu or menus has/have been "executed".

4. If "unit of purchase" functionality is available, pricing information per unit could be added, giving a cost structure per meal. This is not only relevant in a business environment, but it can help common households see, that freshly prepared foods are actually cheaper than pre-processed foods and that the effort of cooking "from scratch" values the time investment made in preparing a meal.

5. Pull-down menus (like "categories") should ideally be alphabetized.

6. The shopping list should be printable in a pre-designed order, to mimick the logistical layout of the supermarket of choice (currently not supported, but a work-around has already been implemented in the initial setup of Gourmet for the restaurant).

The business has a relatively extensive IT-layout, offering access to shared files and databases throughout in order to facilitate business processes. Hence, a central MySQL-database was setup on a server, accessible to all workstations and different users. Servers and workstations run Ubuntu Linux (Servers use the most recent LTS version, workstations the most recent release). It is expected that in 2014 or shortly after, the IT-infrastructure will be augmented by tablet computers running Ubuntu, making Gourmet physically mobile.









--
Harald Franzen
Centre de Plongée Souterraine
Les Trois Fonts
46330 BLARS
La France
I: www.lotcavediving.eu
E: harald.franzen@xxxxxxxxxxxxxxxx
T: +33(0)565-214122
M: +33(0)6-45639437